Rapport PFE - El BARZOUHI - BEGDOURI

ECOLE NATIONALE DES UNIVERSITE
SCIENCES APPLIQUEES DE ABDELMALEK ESSAÂDI

TANGER
PROJET DE FIN D’ETUDES
Présenté à l’Ecole Nationale des Sciences Appliquées de
Tanger pour obtenir le diplôme de
Ingénieur d’état en Génie industriel et logistique
Implémentation d’une solution SAP pour la gestion des
achats au profit de AWB
Réalisé par :
BEGDOURI ACHKARI Ibrahim

EL BARZOUHI Youssef
Encadré par :
M.MOTAKI Noureddine : Professeur chercheur à l’ENSA de Tanger
Mme.OUADY Amal : Manager d’équipe Achat/Logistique à Value Pass Consulting.
Mme.GUEMOURIA Ghita : Consultante fonctionnelle Senior SAP MM/SRM.
Année Universitaire 2016 - 2017
SOUTENU LE 07-07-2017
Avant-propos :
Elèves stagiaires
BEGDOURI ACHKARI Ibrahim

EL BARZOUHI Youssef
Intitulé du travail
Implémentation d’une solution SAP pour la gestion des achats au profit
de AWB
Etablissement d’accueil
VALUE PASS CONSULTING
Encadrants
M.MOTAKI Noureddine Encadrant pédagogique
Mme. OUADY Amal Encadrante professionnelle
Mme. GUEMOURI Ghita Encadrante professionnelle
Période de stage
Début : Mercredi 22 Février 2017 Fin : 30 Juin 2017
Cadre de coopération
Convention entre l’ENSAT et VALUE PASS CONSULTING,
signée en Février 2017.
ii
Dédicaces :
Au Dieu Tout Puissant,
Qui m’a accordé santé, force et courage pendant ces années d’études.
A mes très chers parents,
Je ne saurais trouver assez de mots pour vous exprimer l’estime, le dévouement et l’amour
que je vous porte.
Je vous dédie ce modeste travail pour tous les sacrifices que vous avez consentis pour
mon éducation et mon bien être, Dieu seul sait combien vous en aviez faits. Qu’Allah le
tout puissant vous donne longue vie et santé afin que je puisse vous rendre fiers.
A mes sœurs Sofia, Meriem, Chaimae et à mon frère Mohammed,
Puisse l’amour et la fraternité nous unissent à jamais. Je vous souhaite une vie pleine de
réussite. Qu'Allah vous comble de tout le bonheur que vous méritez.
A mes frères Omar, Saad et Zakariae, comme a dit Frédéric Amiel « un ami
vaut vingt parents », et vous, vous valez la vie ; je vous aime !
A toutes les personnes qui me sont chères,

Qu’elles trouvent ici, le témoignage de tout mon amour et toute ma reconnaissance pour
leur inlassable soutien. Je vous souhaite une vie pleine de joie, de santé et de réussite.
A mon binôme, Begdouri Achkari Ibrahim,

Pour tout ton soutien, ta patience et ta compréhension tout le long de ce projet, je te dis merci
et je te souhaite tout le courage du monde.
EL BARZOUHI Youssef
iii
A ceux qui m’ont donné la vie et m’ont comblé d’affection, de bienveillance et m’ont continuellement
guidé vers le droit chemin… Mes très chers parents.
Ecole de persévérance et de force d’âme, vos efforts et votre dévouement perpétuel et inconditionnel
à me léguer vos vertus de bonté, de générosité et de complaisance ont atteint mes plus profonds
états d’âme. Durant toutes ces années, vous avez veillé à m’instaurer les meilleurs qualités humaines
et du bon musulman, qui ont fait de moi ce que je suis aujourd’hui. Je suis heureux que vos efforts ne
se soient pas dissipés dans le néant, je vous remercie d’avoir cru en moi, malgré mes échecs et mes
défauts, tout mon respect, et toute ma gratitude vous sont destinés. J’implore le Tout Miséricordieux
Allah à vous protéger, et à vous procurer santé, bonheur et vous récompense sans compter ses
paradis, pour vos bonnes œuvres.
Ce modeste travail vous est prioritairement dédié, mais ne représente qu’une petite fraction d’estime
et d’égard que vous méritez. Le meilleur reste à venir…
A mes frères Amine et Muhammad

Symboles de combativité et d’assurance, je vous suis infiniment reconnaissant pour votre dévotion à
m’épauler et me soutenir pour que je sois le meilleur de moi-même.
A mes sœurs, Assia, Soukayna, Oumayma, et la petite Soumayah

Mes fiertés, votre affection est la flamme qui alimente le feu de ma persévérance et mon courage
je vous aime.
A toute ma famille
Tout particulièrement mon oncle Al Habib et ses fils Al Bachir et Ali, je vous remercie pleinement de
vos actions dépourvus d’intérêt. A mes cousins et cousines, Taha, Hamza, Salah, Asmae et Hiba,
grandir à vos côtés a été un plaisir sans équivalent, mes souvenirs avec vous me submergent toujours
d’émotions… Qu’Allah vous protège.
A mes très chers amis,

Oussama El Khalil Houssaini, Salma Souihel, Rajae Boujemaa, Mehdi Elamri, Anass Benabdennbi,
Yassine Banmassoud, Said Akazi, Ihssan Belafia, Ahmed El Youssfi, Youssef Bouymajan, Aymane El
Gueddari, Youssra Taghouti. Aux KBS, Driss Al Ouiqary, Haytam Ouahbi, Youssef Mbarki, Mohammed
Griech, Hamza Koutoun, Hamza Mansori, Jamaleddine Miftah : la vie ne se résume pas à travailler
dur sans répit, elle est aussi faite de rires, de délires et folies… je vous dois tous ces moments de joie.
A mon binôme EL Barzouhi Youssef

Ces quatre mois ont été chargé de missions et de challenges palpitants, j’ai eu le plaisir de les
affronter ensemble, je te souhaite succès et réussite dans tout ce que tu entreprendras inchallah.
iv BEGDOURI ACHKARI Ibrahim

Remerciements :
Nous souhaitons remercier en premier lieu notre encadrant, Monsieur MOTAKI

Noureddine, professeur à l'ENSAT, pour son encadrement hors pair, sa relation et sa proximité
avec les étudiants en général, mais aussi, pour le grand intérêt porté à notre sujet de stage de fin
d'études. Nous le remercions infiniment pour ses conseils très précieux, et on lui exprime notre
entière reconnaissance.
Nous tenons aussi à exprimer nos sincères reconnaissances à notre encadrante professionnelle,
à Value Pass Consulting Mme. GUEMOURIA Ghita, consultante sénior SAP MM et SRM,
pour son aimable soutien, remarques et conseils précieux, et aussi, à notre co-équipière lauréate
de notre école, BOUAOUDA Ouissam, consultante MM, et à tous les membres de l’équipe
MM, tout particulièrement, OUKHEYI Said et EL ALAOUI Ismail.
Nos remerciements vont également à toutes les personnes qu’on a coordonné avec durant
notre stage à Value Pass, auprès desquelles on a trouvé l’accueil chaleureux, l’aide et
l’assistance dont on avait besoin, notamment, Ayoub EL KRIFLI, consultant BC et Aissam
YAAKOUBI, consultant HCM.
Nous devons exprimer nos vifs remerciements à l’ensemble du corps professoral de la filière
génie industriel et logistique pour les efforts qu’ils ne cessent de déployer afin de nous assurer
la meilleure formation.
Nous tenons à remercier également les membres du jury d’avoir accepté d’évaluer notre
travail.
v
Résumé :
Ce présent document résume l’ensemble du travail réalisé durant notre projet de fin d’études,
pour l’obtention de diplôme d’ingénieur d’Etat de l’Ecole Nationale des Sciences Appliquées
de Tanger, en Génie Industriel et Logistique.
Le projet a pris place chez le leader maghrébin dans l’intégration des systèmes d’information,
Value Pass Consulting, partenaire Gold de SAP, ce projet consiste à implémenter une solution
SAP de gestion des achats, au profit d’Attijari Wafa Bank, le leader marocain de son domaine.
Notre ultime objectif est de mettre à disposition notre client d’une solution SAP qui répond aux
mieux à ses besoins, et couvre toutes les exigences exprimées en utilisant les bonnes pratiques
d’achats.
Au cours de la méthodologie d’implémentation ASAP, nous avons contribué dans les phases
de conception et réalisation de projet. Notre travail est partagé en trois grandes parties, nous
avons commencé dans le premier chapitre par le cadrage général du projet pour avoir une
visibilité sur le déroulement des phases du travail, le deuxième chapitre est dédié
essentiellement pour définir les solutions SAP sur lesquels est basé notre projet, à savoir, SAP
ERP, SAP Ariba et SAP SRM, et finalement le dernier chapitre fait décrire l’essentiel de notre
travail réalisé durant toute la période de notre stage.
La dernière partie de ce présent rapport est un récapitulatif et synthèse des acquis que nous
avons développés à partir de notre participation dans le projet, et on présente les résultats
accomplis et les perspectives à réaliser pour la bonne réussite de projet.
vi
Abstract :
The following document sums up the entire work done during our final year project, to achieve
the engineering degree, and obtain the diploma of engineer in logistics and industry.
This project took place within the SME Value Pass Consulting, an SAP Gold Partner, and
aimed to successfully implement the most relevant SAP procurement solution in Attijara Wafa
Bank, a leader of banking industry in Maghreb. The main goal is to provide our client of a
procurement solution which meets his needs, and covers all the requirements using the most
accurate procurement capabilities.
We took part of this project throughout the Business Blueprint and realization phases of
Accelerated SAP methodology. This Project is divided into three essential parts, the first one
describes the general context of this project and its major elements, the second chapter is a
global presentation of three SAP procurement solutions (SAP ERP, SAP Ariba and SAP SRM),
the third part reveals the essence of our work, and uncovers the effective work done all along
the project duration.
The last part of this document synthetize our key benefits from this project, the results
accomplished and the future perspectives that would efficiently enhance and optimize the
procurement process of AWB.
vii
‫ملخص ‪:‬‬
‫التقرير بين أيديكم يلخص العمل المنجز في إطار مشروع التخرج من اجل الحصول على شهادة مهندس دولة من المدرسة‬
‫الوطنية للعلوم التطبيقية بطنجة‪ ،‬شعبة الهندسة الصناعية ًواللوجستيك‪.‬‬
‫تم انجاز هذا المشروع في إطار شراكة ما بين مدرستنا وشركة ‪ ، Value Pass Consulting‬الرائد المغاربي في مجال‬
‫تثبيت النظم المعلوماتية‪ ،‬والشريك الذهبي للرائد األول في العالم في هذا المجال ‪ . SAP‬هذا المشروع تم بهدف توظيف‬
‫نظام ‪ SAP‬لتسيير وتدبير المشتريات‪ ،‬لفائدة التجاري وفا بنك‪ .‬نهدف من خالل هذا العمل توفير نظام يجيب على متطلبات‬
‫‪.‬وحاجيات المعبر عنها من طرف التجاري وفا بنك بشكل أفضل‪.‬‬
‫يتبنى المشروع منهجية ‪ ASAP‬لتثبيت النظم المعلوماتية‪ ،‬والتي شاركنا خاللها في مرحلة التصميم واالنجاز للمشروع‪.‬‬
‫عملنا هذا منقسم لثالثة اجزاء‪ ،‬في االول تم التطرق لإلطار العام من اجل اعطاء رؤية واضحة عن المشروع‪ ،‬ثم تم‬
‫تخصيص الجزء الثاني من اجل التعريف بنظم ‪ SAP‬التي عملنا عليها في مشروعنا هذا‪ ،‬واخيرا وقفنا على اهم العمل‬
‫المنجز في إطار مشروع تخرجنا‪.‬‬
‫تشكل الفقرة االخيرة من هذا التقرير خالصة شاملة على المكتسبات التي تمكنا من ترسيخها وتنميتها من خالل مشاركتنا في‬
‫هذا العمل‪ ،‬كما لخصنا النتائج المنجزة وافاق المشروع التي يجب العمل عليها مستقبال‪.‬‬
‫‪viii‬‬
Liste des acronymes :
ABAP: Advanced Business Application Programming
AMDEC : Analyse des modes de défaillances de leurs effets et de leurs criticités.
AMOA : Assistant à maîtrise d’ouvrage
AO: Appel d’offre
ASAP: Accelerated SAP
ASN : Advance Ship Notice
AWB: Attijari Wafa Bank
BC: BASIS Components
BPMN: Business Process Modeling and Notation
BW: Business Warehouse
CRM: Customer Relationship Management
Dev: Développement
DFS : Distributed file system
ECC: ERP Central Component

ERP: Enterprise Resource Planning
HCM: Human Capital Management
ix
M
MM: Material Management
MOA : Maître d’ouvrage
MOE : Maître d’œuvre
P2O: Procure to Order
P2P: Procure to Pay
PROD: Production
PI: Process Integration

Q
QQOQCP : Qui, Quoi, Où, Quand, Combien, Pourquoi.
Qual : Qualité
SAP: System, Application and Products in data processing
SAP SUS: SAP Supplier Self-Service.
SCN: SAP Community Network.
SI: Système d’information
SIPOC: Supplier, Input, Process, Output, Customer.
SMI: Small and Medium Enterprise.
SRM: Supplier Relationship Management
SWOT: Strength, Weakness, Opportunity, Threats.
TCO: Total Cost of Ownership
VP : Value Pass Consulting
x
Glossaire :
e- Sourcing : Stratégie d’achat d’une entreprise, qui consiste à identifier et sélectionner les
fournisseurs en utilisant au mieux les technologies de l’information.
ASAP : c'est une méthodologie/approche pour l'implémentation de solutions SAP
Report : C'est la présentation périodique de rapports et bilans analytiques sur les activités et
résultats d'une organisation, d'une unité de travail ou du responsable d'une fonction.
Ariba discovery : C’est parmi les points forts de SAP Ariba, c’est une place de marché permet
la découverte des nouvelles opportunités.
xi
Liste des figures :
Figure 1: Organigramme de Value Pass ..................................................................................... 6

Figure 2: Diagramme SIPOC ................................................................................................... 11
Figure 3: Expression du besoin ................................................................................................ 12
Figure 4 : Organigramme du projet .......................................................................................... 13
Figure 5: Démarche ASAP Focus ............................................................................................ 15
Figure 6: Processus de prototypage adopté par Value Pass ..................................................... 15
Figure 7 : Méthodologie ASAP ................................................................................................ 16
Figure 8 : Planning prévisionnel du projet ............................................................................... 18
Figure 9 : plateforme SCRUM ................................................................................................. 20
Figure 10: Environnement de travail SAP ............................................................................... 23
Figure 11: Modules fonctionnelles de SAP.............................................................................. 24
Figure 12: Structure organisationnelle du module MM ........................................................... 25
Figure 13: Processus MM simplifié ......................................................................................... 26
Figure 14: Analyse SWOT de la solution Ariba ...................................................................... 28
Figure 15: Le Processus Achat intégrale sur Ariba .................................................................. 29
Figure 16 : Scénario d'intégration d'Ariba ............................................................................... 30
Figure 17: Cartographie de la solution SRM ........................................................................... 33
Figure 18: Processus du flux classique étendu ......................................................................... 34
Figure 19: Projet de qualification fournisseur .......................................................................... 42
Figure 20: Evaluation des questions......................................................................................... 43
Figure 21: évènements de sourcing .......................................................................................... 43
Figure 22: Minutage d'un événement de sourcing ................................................................... 44
Figure 23: Exemple d'appel d'offre .......................................................................................... 44
Figure 24: Durée de prévisualisation et de réponse ................................................................. 45
Figure 25: Réponse du fournisseur à l'appel d'offre ................................................................. 45
Figure 26: Comparaison des offres et adjudication .................................................................. 46
Figure 27: lots de négociation .................................................................................................. 46
Figure 28: Réponse à l'enchère................................................................................................. 47
Figure 29: suivi et contrôle de l'enchère en temps réel: ........................................................... 47
Figure 30: Processus de gestion d'un projet contrat ................................................................. 48
Figure 31: Exemple de catalogue de SAP Ariba ...................................................................... 50
Figure 32: Ajout d'articles au panier ........................................................................................ 50
xii
Figure 33: Procédure d'approbation d'une DA ......................................................................... 50
Figure 34: Commande d'achat .................................................................................................. 51
Figure 35: Réception de marchandises..................................................................................... 51
Figure 36: Etapes de réception de marchandises ..................................................................... 51
Figure 37: Champs d'un report ................................................................................................. 52
Figure 38: Report montant total commande par fournisseur.................................................... 52
Figure 39 : Environnement AWB DEV ................................................................................... 54
Figure 40 : schéma cible fonctionnel ....................................................................................... 55
Figure 41 : Activation de live auction cockpit ......................................................................... 59
Figure 42 : paramétrage de type d'enchères ............................................................................. 59
Figure 43 : Définition des types d'enchères ............................................................................. 60
Figure 44 : paramétrage de bon de réception ........................................................................... 60
Figure 45 : définition des conditions d'impression .................................................................. 61
Figure 46 : Activation de service auto-enregistrement ............................................................ 62
Figure 47 : test du service auto-enregistrement ....................................................................... 62
Figure 48 : formulaire d'auto-enregistrement ........................................................................... 62
Figure 49 : Sélection des fournisseurs...................................................................................... 63
Figure 50 : Choix de catégorie d'évaluation ............................................................................. 63
Figure 51 : exemple de formulaire d'évaluation ....................................................................... 64
Figure 52 : Définition de type des contrats et tranches de numéros ........................................ 64
Figure 53 : Diagramme de Gantt réel ....................................................................................... 66
xiii
Liste des tableaux :
Tableau 1: Questions QQOQCP .............................................................................................. 10

Tableau 2 : Structure de la charte du projet ............................................................................. 14
Tableau 3: Classe d'occurrence et de détectabilité ................................................................... 17
Tableau 4: Classe de gravité..................................................................................................... 19
Tableau 5: Classification des solutions Ariba .......................................................................... 31
Tableau 6: Comparaison de SAP Ariba et SAP SRM .............................................................. 35
Tableau 7: Fonctionnalités demandées par le client................................................................. 38
Tableau 8 :Propriétés des types article ..................................................................................... 57
Tableau 9: Propriétés de gestion fournisseur ........................................................................... 57
Tableau 10: Bilan des réunions ................................................................................................ 67
Tableau 11 : Bilan des supports sur Ariba ............................................................................... 68
Tableau 12 : Bilan des supports sur SRM ................................................................................ 68
xiv
Table des matières
Avant-propos : ............................................................................................................................ ii
Dédicaces : ................................................................................................................................ iii
Remerciements : ......................................................................................................................... v
Résumé : .................................................................................................................................... vi
Abstract : .................................................................................................................................. vii
: ‫ ملخص‬....................................................................................................................................... viii
Liste des acronymes : ................................................................................................................ ix
Glossaire : .................................................................................................................................. xi
Liste des figures : ..................................................................................................................... xii
Liste des tableaux : .................................................................................................................. xiv
Introduction générale : ............................................................................................................... 1
Chapitre 1 : Cadre général du projet .......................................................................................... 3
1. Contexte général du projet : ................................................................................................... 4
1.1. Contexte académique :..................................................................................................... 4
1.2. Contexte professionnel : .................................................................................................. 4
1.2.1. Organisme d’accueil : VALUE PASS Consulting.................................................... 4
1.2.2. Organisme client : Attijari Wafa Bank ..................................................................... 7
2. Cahier des charges :................................................................................................................ 8
2.1. Objectifs du projet : ......................................................................................................... 8
2.2. Services assurés par VP : ................................................................................................. 9
2.3. Définition de la problématique : .................................................................................... 10
2.4. Analyse SIPOC : ............................................................................................................ 10
2.5. Etude de besoin :............................................................................................................ 12
3. Management de projet : ........................................................................................................ 13
3.1. Acteurs du projet : ......................................................................................................... 13
3.2. Charte du projet : ........................................................................................................... 14
3.3. Conduite du projet : ....................................................................................................... 14
3.3.1. L’approche du prototype : ....................................................................................... 14
3.3.2. La méthodologie ASAP : ........................................................................................ 16
3.4. Nos missions du projet : ................................................................................................ 16
3.5. Planning prévisionnel et réel du projet : ........................................................................ 17
3.6. Analyse des risques : AMDEC ...................................................................................... 17
3.7. La méthodologie SCRUM : .......................................................................................... 19
Conclusion :.............................................................................................................................. 20
Chapitre 2 : Environnements SAP et étude de l’existant ......................................................... 21
1. Présentation de SAP ERP :................................................................................................... 22
1.1. Définition de l’ERP : ..................................................................................................... 22
1.2. Présentation de SAP : .................................................................................................... 22
1.3. Les environnements de travail : ..................................................................................... 23
xv
1.4. La gestion intégrée par SAP ECC : ............................................................................... 23
1.5. Le module MM : Gestion des articles : ......................................................................... 24
1.5.1. La structure organisationnelle : ............................................................................... 25
1.5.2. Les données de base du module MM :.................................................................... 25
1.5.3. Le flux du processus achat sur MM : ...................................................................... 25
1.6. Limites de la gestion des achats sur SAP ERP : ........................................................... 26
2. La gestion des achats sur ARIBA : ...................................................................................... 27
2.1 Présentation d’Ariba : ..................................................................................................... 27
2.2. Analyse SWOT : ............................................................................................................ 28
2.3. Processus planifier, acheter et payer : ........................................................................... 29
2.4. Ariba Cloud Procurement Menu : ................................................................................. 29
2.5. Classification des solutions Ariba : ............................................................................... 30
3 .SAP SRM : ........................................................................................................................... 32
3.1. Présentation de SRM ..................................................................................................... 32
3.2. La solution SAP SRM : ................................................................................................. 32
3.3. Cartographie de la solution SRM : ................................................................................ 33
3.4. Scénarios de déploiement SAP SRM : .......................................................................... 33
3.4.1. Applicabilité du scénario classique étendu : ........................................................... 33
3.4.2. Processus du scénario classique étendu : ................................................................ 34
3.5. Comparaison entre SRM et Ariba : ............................................................................... 35
4. Etude de l’existant : .............................................................................................................. 36
4.1. Le As Is :........................................................................................................................ 36
4.1.1. Paysage applicatif d’AWB :.................................................................................... 36
4.1.2. Etat des lieux du projet : ......................................................................................... 37
4.1.3. La situation actuelle de la gestion des achats sur AWB: ........................................ 37
4.2. Le To Be : ...................................................................................................................... 37
Conclusion :.............................................................................................................................. 39
Chapitre 3 : Design de la solution de gestion des achats ......................................................... 40
Partie 1 : Déroulement du flux du processus achat sur la solution Ariba pré-packagée .......... 41
1. Projet de sourcing : ........................................................................................................... 41
1.2. Projet de qualification fournisseur : ........................................................................... 42
1.2. L’appel d’offre : ......................................................................................................... 44
1.3. L’enchère inversée : ................................................................................................... 46
2. Gestion des contrats : ........................................................................................................ 48
3. Processus P2O : ................................................................................................................ 49
4. Reporting : ........................................................................................................................ 52
Transition de SAP Ariba à SAP SRM :.................................................................................... 53
Partie 2 : Conception et réalisation de SAP SRM ................................................................... 54
1. Lancement de la conception : ........................................................................................... 54
1.1. Installation du système de SAP SRM et activation de préconfigurés :...................... 54
1.2. Modélisation du processus cible AWB : .................................................................... 55
xvi
2. Conception de SAP SRM : ............................................................................................... 56
2.1. Définition des règles de gestion : ............................................................................... 56
2.2. Identification des processus à paramétrer : ................................................................ 58
2.3. Rédaction des fiches de conception : ......................................................................... 58
3. Paramétrage et réalisation :............................................................................................... 59
3.1. Paramétrage live auction cockpit : ............................................................................. 59
3.2. Paramétrage des catégories message – Bon de réception : ........................................ 60
3.3. Paramétrage d’auto-enregistrement des fournisseurs : .............................................. 61
3.4. Paramétrage de présélection fournisseur : ................................................................. 62
3.5. Paramétrage d’évaluation fournisseur : ..................................................................... 63
3.6. Paramétrage de gestion des contrats : ........................................................................ 64
Conclusion :.............................................................................................................................. 65
Bilan et perspectives du projet : ............................................................................................... 66
1. Bilan du travail réalisé : .................................................................................................... 66
1.1. Comparaison du planning réel et prévisionnel : ........................................................ 66
1.2. Bilan des réunions effectuées : .................................................................................. 67
1.3. Supports réalisés : ...................................................................................................... 67
2. Bilan de compétences : ..................................................................................................... 69
2.1. Compétences utilisées : .............................................................................................. 69
2.2. Compétences développées : ....................................................................................... 69
3. Perspectives : .................................................................................................................... 70
3.1. Perspectives du projet : le ‘Should Be’ ...................................................................... 70
3.2. Perspectives professionnelles : .................................................................................. 70
3.3. Conduite du changement : ......................................................................................... 71
Conclusion générale : ............................................................................................................... 72
BIBLIOGRAPHIE ................................................................................................................... 74
WEBOGRAPHIE ..................................................................................................................... 74
ANNEXES ............................................................................................................................... 75
Liste des annexes :.................................................................................................................... 76
xvii
Introduction générale :
Avec plus de quarante ans d’existence, les ERP structurent le paysage des systèmes
d’information des entreprises industrielles, commerciales et financières. Un projet d’ERP est
durable, car après avoir été l’un des vecteurs majeurs de maîtrise du back office et des chaînes
logistiques, il présente un moyen de résister à une économie perturbée, d’innovation continue
en intégrant les nouvelles technologies et en s’inscrivant sur des nouveaux modèles
économiques. Dans cette optique d’informatisation des processus logistiques, et grâce au
concept de l’e-sourcing, la gestion des achats classique a connu une mutation vers une
recherche de sources d’approvisionnement plus ciblée et qui répond au mieux aux besoins de
l’acheteur. Ceci dit, l’e-sourcing est devenu un outil puissant d’identification des fournisseurs,
et de gestion de relation avec eux de façon simple et harmonieuse en utilisant au mieux les
technologies de l’information. Par conséquent, les entreprises se voient séduites par un système
d’information de gestion des achats, qui confie pleinement un avantage de compétitivité et de
maîtrise des dépenses achat.
A cet égard, le groupe Attijari Wafa Bank, premier groupe bancaire et financier du Maghreb,
conscient de l’apport d’un tel système au niveau de la fiabilité, cohérence et simplicité de
l’utilisation des données liées à son processus d’achat, a choisi d’intégrer une solution SAP
pour mieux gérer la relation avec ses fournisseurs et gérer ses achats. Le groupe veille à ce que
la solution couvre un ensemble de fonctionnalités, et répond à plusieurs enjeux stratégiques,
organisationnels mais aussi technologiques, sans oublier que la solution devra également
s’intégrer avec son système applicatif existant. En réponse à cette demande, Value Pass
Consulting, partenaire gold de SAP, est rentrée en collaboration avec le groupe Attijari sous la
casquette d’intégrateur pour s’aligner avec la perspective du groupe, répondre à ses attentes, et
mener à bien ce projet de refonte du système d’information. Notre projet consiste donc à mettre
en place une solution SAP de gestion des achats et de gestion de relation fournisseur au service
du groupe Attijari Wafa Bank. Cette solution a comme objectif de rationaliser les achats du
groupe AWB et de maîtriser l’ensemble du processus achat. Pour la bonne gestion de ce projet,
Value Pass Consulting a choisi la méthodologie ASAP pour la gestion de ce projet, de la
préparation initiale jusqu’au support et maintenance. Nous avons pu participer dans ce projet,
durant la deuxième et la troisième phase du processus ASAP, qui sont la conception de la
solution et sa réalisation.
1 PFE ǁ Implémentation d’une solution SAP pour la gestion des achats

Le présent rapport est une vue d’ensemble du travail réalisé durant quatre mois. Nous avons
scindé le rapport selon une structure cohérente en quatre parties. Afin de mieux cadrer notre
projet, délimiter son périmètre et mieux élucider sa problématique, nous avons présenté en
première partie le contexte général du projet, soit le cadre académique et professionnel,
l’organisme d’accueil, l’étude du besoin, le cahier des charges fonctionnelles, les missions
affectées et le management du projet.
Avant de se lancer dans le travail réalisé, et dans le but d’apporter au lecteur une vision sur
les requis pour mieux se situer dans nos réalisations, nous avons présenté en deuxième partie
les différentes solutions incorporées et utilisées dans ce projet, et leurs différentes
fonctionnalités, pour se positionner au final sur la solution qui répond au mieux au besoin
d’AWB. Nous avons abordé par la suite une étude de l’existant, qui met la lumière sur
l’architecture technique existante, l’état actuel et l’état futur.
Finalement, le fruit de notre travail est présenté au 3ème chapitre, et englobe tout ce qui a été
concrètement réalisé durant notre projet de fin d’études. Ce chapitre est divisé en deux grandes
parties, la première concerne la réalisation d’un prototype système SAP Ariba, qui comprend
l’intégralité du flux du processus achat. Après l’éclaircissement de la transition de SAP Ariba
à SAP SRM, nous avons traité en deuxième partie la conception de la solution SAP SRM qui
identifie principalement les processus métier à paramétrer et les règles de gestion établies, qui
sont l’un des constituants majeurs de la fiche de conception, le livrable principal de cette étape.
Ensuite nous avons présenté les différents paramétrages effectuées qui constituent les éléments
clés de la phase de réalisation. Ce rapport a été clôturé par un bilan et des perspectives de notre
projet de fin d’études.

Chapitre 1 : Cadre général du
projet
Cadre général du projet

.
Dans ce chapitre, nous avons situé notre projet de

fin d’études dans les deux contextes où il s’insère, à
savoir le contexte académique relatif à notre cursus
scolaire, et le contexte professionnel lié au projet
qui nous a été confié au sein de VALUE PASS
Consulting. Et nous avons présenté le cahier des
charges, et la partie management du projet.
Plan
- Contexte général
- Cahier des charges
- Management du projet

Chapitre 1 : Cadre général du projet
1. Contexte général du projet :

1.1. Contexte académique :
Le projet de fin d’études est la dernière étape du parcours scolaire qui marque la fin de la
phase de formation au sein de l’Ecole Nationale des Sciences Appliquées de Tanger. Ce
parcours qui s’étale sur cinq ans d’études se déroule comme suit :
 Deux années préparatoires où l’étudiant est censé acquérir les connaissances de base et
les outils nécessaires pour un futur ingénieur.
 Trois ans en cycle ingénieur qui visent à développer le savoir-être et le savoir-faire de
l’élève ingénieur dans le but de le préparer à l’insertion professionnelle.
Ce présent travail est réalisé dans le cadre du projet de fin d’études qui s’est déroulé au
deuxième semestre de la 3ème année du cycle ingénieur, dans le but d’obtenir le diplôme
d’ingénieur d’Etat en génie industriel et logistique. Il a été réalisé au sein de la société VALUE
PASS Consulting, sous l’encadrement de la société elle-même et l’ENSAT.
L’encadrement au cours du déroulement du projet a été assuré par M. MOTAKI Noureddine,
professeur à l’ENSA de Tanger. La validation du travail réalisé est une tâche attribuée aux
membres constitutifs du jury de à l’ENSAT. Ce jugement est porté suite à une soutenance où
l’essentiel du travail sera présenté, et suite à l’évaluation de la qualité du rapport de synthèse.
1.2. Contexte professionnel :
Le projet de fin d’études est une étape nécessaire qui a pour but de faciliter la transition vers
le monde professionnel. Non seulement c’est une opportunité pour mettre en pratique
l’ensemble des connaissances et savoir-faire acquis durant le cursus scolaire, mais aussi une
occasion pour apprendre à s’adapter avec les différentes situations purement professionnelles.
Dans ce qui va suivre on va présenter l’organisme d’accueil, VALUE PASS Consulting, les
métiers exercés dans le cadre du projet ainsi que les différentes missions qui nous ont été
confiées.
1.2.1. Organisme d’accueil : VALUE PASS Consulting
VALUE PASS est un intégrateur d’ERP – SAP, mais aussi une boîte de conseil en
organisation.
Créée en 2005, elle constitue une réponse à un besoin accru en professionnels qualifiés
maîtrisant les standards internationaux en matière d’intégration d’ERP.
La société, qui s’appuie sur une équipe de consultants de très bon niveau, offre ses services aux
multinationales implantées au Maghreb et aux grands comptes publics et privés.
Consciente de l’évolution de l’économie nationale, l’entreprise a développé une offre
d’intégration de SAP adaptée aux PME.
Missions :
La mission de VALUE PASS consiste à développer une offre de consulting basée sur la
proximité et l’excellence. A assurer également des services de qualité et un accompagnement
durable de ses clients. Son offre comprend une palette de prestations organisées autour de cinq
métiers :
 Conseil en management et Organisation
 Conseil et Implémentation des ERP
 Formation aux ERP
 Développements Off-shore
 Développement sur les technologies ABAP
Métiers :
Conseil et intégration ERP :
L’intégration des ERP constitue le cœur de métier de VALUE PASS, s’appuyant sur son fort
partenariat avec SAP ainsi qu’avec des intégrateurs de référence (IBM Global Business
Services), VALUE PASS participe à des projets complexes d’intégration, allant de la
conception à l’intégration et la mise en œuvre de solutions technologiques.
Son approche est basée sur les retours d’expériences de mise en œuvre de projets ERP dans le
monde et privilégie les chantiers à valeur ajoutée pour l’entreprise. Son offre comprend le
pilotage des projets, l’intégration des projets ERP, l’assistance à maîtrise d’ouvrage,
l’assistance au choix et comparaison des solutions et la rédaction de cahier des charges et
spécifications fonctionnelles.
Conseil en Management & Organisation :
Positionnée sur le marché du conseil en management et en organisation et dotée d’expertises
sectorielles et fonctionnelles de premier plan, VALUE PASS a pour ambition d'aider ses clients
à identifier, structurer et exécuter leurs projets de transformation qui impactent durablement
leurs croissance ou leurs compétitivité. Le cabinet les accompagne dans leurs phases de
transition en portant une grande attention aux facteurs clés d’une transformation réussie.

Formation aux ERP

En fonction des besoins de l'entreprise, Value Pass assure des formations sur mesure, destinées
aux utilisateurs de son système ERP. Les formations sont dispensées par des consultants experts
en intégration des ERP doublé d’une maîtrise pédagogique acquise grâce aux sessions de
formations animées au Maroc et en France.
Développement Offshore
La société s’appuie sur son expérience et son savoir-faire dans le domaine de l’intégration des
SI pour accompagner ses clients dans la prise en charge et l’évolution de leurs systèmes
d’informations et à faire face avec eux à leurs enjeux métiers.
Développement sur les technologies ABAP
Ce volet comprend :
 Le développement autour des outils décisionnels comme BW.
 La maintenance applicative à distance des systèmes d’information des clients basés
à l’étranger.
 Le paramétrage en centre permettant de personnaliser le progiciel ;
 L’analyse pour le compte des multinationales en utilisant des outils statistiques.
Organigramme :
Figure 1: Organigramme de Value Pass

VALUE PASS se compose de consultants techniques et fonctionnels en SI, prêts à accompagner

le client depuis le choix de sa solution jusqu’à sa mise en œuvre. (Voir figure 1)
Pour notre projet, nous avons travaillé au sein de l’équipe fonctionnelle MM.
Référence :
VALUE PASS a déjà effectué plusieurs projets SAP et Organisation dans les différents
pays du Maghreb notamment le Maroc, l'Algérie et la Tunisie qui font que sa renommée
s'accroît de plus de plus dans ses domaines. Parmi les maints projets réalisés on cite les plus
marquants :
 La Mise en place des procédures de suivi des dépenses marketing et la gestion de
facturation inter-compagnie pour le compte de Coca Cola.
 La mise en place de SAP S/4 Hana pour l’Université Mohammed 6 Polytechnique.
 L’implémentation de SAP ERP au service de l’OCP Africa, intégration des modules
MM, FICO, SD sur 14 pays en Afrique.
1.2.2. Organisme client : Attijari Wafa Bank
Le groupe Attijari Wafa Bank, premier groupe bancaire et financier du Maghreb, avec 7,4
millions de clients et 16 716 collaborateurs, est une multinationale panafricaine.
Présent dans 24 pays, le Groupe se donne pour priorité la proximité avec ses clients et les met
au cœur de sa stratégie via son ambitieux programme de bancarisation et ses efforts
d’innovation continus. En plus de l’activité bancaire, le Groupe opère, à travers des filiales
spécialisées, dans tous les métiers financiers : assurance, crédit immobilier, crédit à la
consommation, leasing, gestion d’actifs, intermédiation boursière, conseil, location longue
durée, factoring…
Doté d’une assise financière solide, d’un capital de savoir-faire diversifié et d’outils
d’expertise modernes, le Groupe a réussi à se hisser en leader national incontesté des crédits à
l’économie et des crédits à la consommation, des activités de corporate banking et de banque
d’investissement, de la gestion d’actifs et des métiers de la bourse, du leasing et de la
bancassurance.
Attijari Wafa Bank est basé au Maroc et opère dans 23 pays : en Afrique (Tunisie,
Sénégal, Burkina-Faso, Guinée Bissau, Mali, Mauritanie, Côte-d’Ivoire, Congo,
Gabon,Cameroun, Togo et Niger) et en Europe (Belgique, France, Allemagne, Pays-Bas, Italie
et Espagne) à travers des filiales bancaires contrôlées majoritairement par la banque à Dubaï,
Riyadh, Londres, Shanghai et Tripoli à travers des bureaux de représentation.

Domaines d'activités :
L’organisation d’Attijari Wafa Bank vise à placer le client au centre des préoccupations du
groupe, et à assurer un service conforme aux meilleurs standards, grâce à une technologie à la
pointe de l’innovation. Ses principaux domaines d’activités sont :
 Activités de Financement et des Marchés.

 Banque de détail à l'international.
 Services financiers spécialisés.
2. Cahier des charges :
Notre projet s’inscrit dans le cadre de la mise en place d’une solution de gestion des achats
pour le compte du leader bancaire marocain Attijari Wafa Bank.
Les achats à l’Attijari Wafa Bank reposent sur certains critères formels imposés par les règles
et procédures internes des achats fortement inspirés des standards internationaux, à savoir :
 La transparence des procédures achats ;

 L’égalité d’accès des concurrents aux commandes (égalité de traitement des
concurrents) ;
 Assurer l’efficacité économique des achats.
C’est dans cette optique, qu’AWB a fixé des enjeux stratégiques, organisationnels et
technologiques (voir annexe 1) pour maintenir sa concurrence, et créer de la valeur via la mise
en place d’une solution de gestion des achats.
2.1. Objectifs du projet :
AWB a pu exprimer son besoin d’une solution de gestion des achats en recensant les différentes
fonctionnalités attendues de cette solution. (Voir annexe 1)
Les enjeux déterminés par AWB cadrent plusieurs objectifs à atteindre en mettant en œuvre la
solution SAP, à savoir :
 Construire avec l'écosystème des achats une relation bâtie sur la transparence et la
confiance ;
 Disposer d'un outil de pilotage des achats efficients ;

 Aligner les processus, les systèmes et l’organisation ;

 Réussir le changement avec l’adhésion des ressources humaines ;
 Standardisation des processus d'achats ;
 Utilisation des meilleures pratiques sectorielles ;
 Utilisation des dernières innovations technologiques ;
 Diminuer les délais de traitement de l’information ;
 Améliorer la fiabilité des informations.
2.2. Services assurés par VP :
En tant qu’intégrateur des SI, Value Pass a entré dans un cadre de coopération avec AWB,
dans l’optique d’assurer certains services dont elle est spécialisée.
Généralement, dans la première phase de chaque projet d’implémentation, un cahier de

charges préalablement établi décrit les périmètres et services que doivent être assurés, soit de
la part du client, soit de la part de Value Pass, on décrit ci-après les responsabilités de chaque
partie prenante sur les périmètres organisationnel, fonctionnel et technique.
Périmètre organisationnel : Le projet portera sur l’entité d’achats centrale d’Attijari Wafa
Bank seulement, par contre, le déploiement sur les différentes entités régionales sera fait par
l’équipe interne d’AWB.
Périmètre fonctionnel : En plus de savoir-faire, et de maitrise de la solution proposée, Value

Pass propose un service qui couvre l’ensemble des fonctionnalités exprimées par AWB.
Périmètre technique : Value Pass assure dans le cadre de projet, les développements
nécessaires en cas de besoin, tout en adoptant les bonnes pratiques SAP en termes de
développement.
En addition à l’ensemble des services qui seront implicitement assurés par Value Pass
Consulting lors de la phase de conception et de réalisation, Value Pass s’engage aussi à assurer
les services suivants :
 Migration de données
 Formation des key et end users
 Maintenance
Les différentes responsabilités et activités des deux parties prenantes durant les grandes
phases du projet sont présentées en annexe 5.

2.3. Définition de la problématique :
Dans l’objectif de mieux souligner la grande problématique de ce projet, nous la définissons

comme suit : ‘La rationalisation des achats au sein d’un seul système adapté, structuré et
intégrable’.
Pour bien cadrer la problématique de ce présent travail, le tableau 1 QQOQCP suivant est très
utile pour la bonne compréhension des éléments en interaction avec la problématique.
QQOQCP
Qui ? Attijari Wafa Bank
Value Pass consulting
Equipe MM/Logistique
Quoi ? Absence d’un système d’information de gestion des achats
Travail lourd et fastidieux pour passer et gérer les documents achat
Problème d’incohérence et de redondance des données
Où ? L’entité d’achat centrale d’AWB
Quand ? Depuis l’expression du besoin d’achat
Comment ? Analyse de l’existant
Choix de la solution de gestion d’achat
Conception de la solution
Paramétrage de la solution
Implémentation de la solution
Pourquoi ? Eliminer l’incohérence
Rationaliser les achats
Organiser le processus achat efficacement
Contrôler les dépenses
Tableau 1: Questions QQOQCP
2.4. Analyse SIPOC :
Afin de mieux définir les différents éléments (parties prenantes, entrées, sorties) du processus
achat qu’on souhaite améliorer grâce à l’intégration d’une solution SAP de gestion des achats,
nous avons mis en place un diagramme SIPOC qui identifie les éléments du processus
d’implémentation de la solution SAP. Nous avons fragmenté les constituants des blocs entrées,

processus et sorties, et nous avons déterminé les différents liens qui existent entre eux. La figure
2 représente la forme éclatée du diagramme SIPOC.
Conception de
Cahier des charges
la solution
fonctionnelles
Fiches de
conceptions
Processus Rédaction des
détaillées
métier documents
fonctionnels Documents de
Equipe MM paramétrage
fonctionnelle Paramétrage
des processus
Equipe
Technique
Smart Stream
Intégration
Environnement de intégré avec la
des systèmes
DEV et QUAL solution SAP
d’information
Système
d’information
Smart Stream
Canevas de Migration des Données

correspondance données chargées
Figure 2: Diagramme SIPOC

2.5. Etude de besoin :
La solution mise en œuvre doit répondre parfaitement à l’exigence exprimée par AWB et
couvrir l'ensemble des fonctionnalités demandées, et ainsi atteindre les objectifs fixés au
préalable. La figure 3 traduit l’expression du besoin de projet.
Direction Achat
Processus Achat
Attijari Wafa Bank
Implémentation d’une
solution SAP pour la
gestion des achats
Permettre de gérer les achats et la relation

fournisseur
Figure 3: Expression du besoin
La source du besoin d’AWB à un système de gestion des achats réside dans le fait que leur
système d’information ne supporte pas des solutions pour la gestion du processus achat. Les
différentes fonctionnalités que couvre ce système sont présentées dans la partie de l’étude de
l’existant au chapitre 2, elles ne couvrent que la partie de la gestion des factures au sein du
processus achat. Le besoin d’intégrer une solution SAP, ne se résume pas à pouvoir gérer le
processus achat, car il est toujours possible de faire des développements spécifiques sur l’ancien
système pour qu’il puisse intégrer les différents éléments du processus achat. Cependant, le prix
du développement spécifique est généralement très onéreux et le résultat n’est pas toujours
satisfaisant. Le besoin d’intégrer une solution SAP pour la gestion des achats avec l’ancien
système s’accentue aussi du fait que l’implémentation d’un tel système implique l’adoption
d’une grande partie de ses bonnes pratiques.

3. Management de projet :
Pour la bonne gestion de notre projet, nous avons établi les éléments indispensables pour avoir
une visibilité sur le déroulement du travail. Dans ce qui suit, nous allons présenter les acteurs,
la méthodologie de projet ASAP FOCUS, charte du projet (contraintes, objectif stratégique du
projet etc.) et risques projet.
3.1. Acteurs du projet :
Le projet est géré par l’équipe MM/logistique principalement pour le périmètre fonctionnel en
collaboration avec l’équipe technique pour le périmètre technique, les deux sont orientées par
un comité de suivi et un comité de pilotage. L’organigramme du projet est décrit dans la
figure 4.
Les rôles des intervenants sur le projet sont décrits dans l’annexe 2.
• Sponsor projet Attijariwafa bank

Comité de pilotage • Chef de projet Attijariwafa bank
• Chef de projet AMOA
• Direction projet VP
• Chef de projet Attijariwafa bank

Comité de suivi • Chef de projet AMOA
• Chef de projet VP
Achats & Marchés Technique
 Chef projet domaine VP • Chef de projet technique

 Garant métier /Architecte VP
 AMOA • Chef de projet technique AWB
 Consultant(s) • Développeurs VP
 Equipe projet AWB • Développeurs AWB
 Utilisateurs Clé • Administrateur VP
• Administrateur AWB
Figure 4 : Organigramme du projet

3.2. Charte du projet :
La charte de projet est un document qui définit et autorise formellement un projet. Même si sa
conception peut apparaître comme un processus délicat, son contenu doit donner une vision
claire et enlever toute ambiguïté pour tous les acteurs du projet.
En collaboration avec l’équipe de projet, nous avons pu construire la charte du projet dont les
éléments constitutifs sont cités dans le tableau 2 ci-dessous. (Voir annexe 3)
Données générales Définition du projet Autres paramètres
Intitulé du projet Objectif et lien stratégique Budget de projet
Date/Version Objectif spécifique Contraintes connues
Chef de projet Bénéfices recherchés Impact sur la société
Stratégie de réalisation du Responsabilités du comité de
projet pilotage
Principaux livrables et dates Critères de terminaison de
prévues projet
Tableau 2 : Structure de la charte du projet
3.3. Conduite du projet :
Un projet qui porte sur l’implémentation d’une solution SAP représente en général un
investissement onéreux et relativement long à mettre en œuvre. De ce fait, Value Pass propose
une approche par étapes, permettant :
 D’avoir très tôt dans le projet une version adaptée au contexte particulier du client.
 D’assurer la cohérence de la solution avec les processus cibles grâce à une approche par
écarts.
 D’éviter les développements spécifiques.
La figure 6 présente la démarche adoptée par VALUE PASS ASAP Focus.
3.3.1. L’approche du prototype :
Cette méthodologie présente l’avantage de la rapidité quant à l’ajustement des besoins métiers
avec le progiciel. La notion de prototypage implique une collaboration directe et complète des
agents opérationnels, propres au métier, que nous appelons Utilisateurs Clés ou Experts
Métiers.

Figure 5: Démarche ASAP Focus
La plupart des travaux se font en équipe mixte composée MOA/MOE générant ainsi un
équilibre des charges entre les différents acteurs.
Dès le début du projet, Value Pass adopte une approche de conception et de prototypage
(présentée dans la figure ci-après) afin de mettre à disposition :
 Un prototype V1 présentable.
 Le prototype est construit pour l’ensemble des activités et des processus.
 Une version finalisée (V2) ajustée.
 Partir du prototype SAP pour effectuer la refonte des processus.
Figure 6: Processus de prototypage adopté par Value Pass

 Les ateliers d’analyse d’écart sont organisés en s’appuyant sur le système paramétré
 Le niveau de paramétrage de la solution évolue de manière itérative : d’une solution ‘de

base’, elle évoluera au fur et à mesure des ateliers vers le prototype V1 (dans certains
cas de processus complexes, 2 ou 3 réunions seront nécessaires pour converger).
 Dans certains cas, les solutions proposées sont en écart par rapport à la cible, l’écart est
alors identifié et remonté au comité de projet (et éventuellement comité de pilotage pour
arbitrage)
 Un soin particulier doit être apporté à cette identification des écarts entre les meilleures
pratiques de SAP et les processus ‘cible’ Attijari Wafa Bank, afin de limiter les coûts
de traitement futurs.
3.3.2. La méthodologie ASAP :
D’un point de vue méthodologique et en tenant compte des caractéristiques du projet, Value
Pass propose une approche baptisée « ASAP – Accelerated SAP » (préconisée par SAP),
laquelle est décomposée en 5 étapes présenté dans la figure suivante et détaillées dans l’annexe
4.
PHASE 2 PHASE 4
•Préparation du •Démarrage
projet •Conception •Réalisation et
recette •Préparation
Prototype / finale et support
analyse d'écart
PHASE 1 PHASE 3 PHASE 5
Figure 7 : Méthodologie ASAP
3.4. Nos missions du projet :
Au sein de l’équipe Achat/Logistique (MM/SRM/Ariba), nous avons contribué aux phases

conception et réalisation de l’implémentation de la solution de gestion des achats, où on était
amenés à dérouler le flux d’achat sur SAP Ariba et faire le paramétrage sur SAP SRM.

Nos missions durant ce projet tournent autour de :
 Etude de SAP Ariba

 Déroulement du flux P2O sur SAP Ariba
 Conception de la solution SAP SRM
 Réalisation des paramétrages sur le système SAP SRM,
 Elaboration des documents fonctionnels
 Réalisation des tests unitaires et d’intégration
 Réalisation des recettes avec le client
3.5. Planning prévisionnel et réel du projet :
Comme pour chaque projet, un planning prévisionnel s’avère très nécessaire pour le bon
déroulement du travail. En collaboration avec le chef du projet, nous avons élaboré le planning
prévisionnel, présenté dans la figure 9 ci-dessous.
A cause des contraintes définies dans la charte du projet, nous étions obligés de décaler quelques
dates dans notre Gantt, ce qui dit qu’on aura un diagramme réel.
(Voir le planning prévisionnel détaillé dans annexe 6).
3.6. Analyse des risques : AMDEC
L’AMDEC est une méthode inductive d’analyse de la fiabilité d’un système. A partir de la
défaillance (ou de la combinaison de défaillances) d’un composant et de la structure
fonctionnelle du système, on étudie le lien entre cette défaillance et ses conséquences sur le
service rendu par le système.
La détermination des valeurs de G (gravité), O (occurrence) et D (détectabilité) s’est faite

selon l’échelle présentée dans les tableaux 2 et 3.
Classe d’occurrence Classe de détectabilité

Occurrence Notation Occurrence Notation
Fréquent 10 Aucune 10
Occasionnel 7 Faible 7
Rare 4 Probable 4
Jamais 1 Totale 1
Tableau 3: Classe d'occurrence et de détectabilité

Figure 8 : Planning prévisionnel du projet
18SAP pour la gestion des achats

PFE ǁ Implémentation d’une solution
Classe de gravité
Occurrence Notation
Catastrophique 10
Majeur 9
Moyenne 6
Mineur 3
Minime 1
Tableau 4: Classe de gravité
En collaboration avec l’équipe de projet nous avons pu recenser les multiples risques
susceptibles de se produire. Le tableau 4 ci-dessous présente la grille des risques élaborée avec
la notation.
Le tableau intégral de l’analyse AMDEC Projet est en annexe 7.
3.7. La méthodologie SCRUM :
Afin de contourner les obstacles de communication, d’absence de suivi des tâches, et de manque
de visibilité sur l’ensemble des actions à exécuter, nous avons jugé utile de travailler avec la
méthodologie SCRUM pour la bonne conduite de notre projet. Nous n’avons pas respecté
l’intégralité des concepts de cette méthode, mais nous en avons tiré les bonnes pratiques de
communication et d’organisation des tâches au sein de notre équipe interne.
SCRUM est un schéma d’organisation de développement de produits complexes. Il fonctionne

en mode agile, ce qui signifie de façon incrémentale et itératif. Ce schéma d’organisation
s’appuie sur le découpage d’un projet en boîtes de temps, nommés sprints. Un sprint peut durer
entre quelques heures et un mois. Dans notre cas, nous avons fixé une durée de deux semaines
aux sprints pour être plus flexible et ne pas se surcharger de travail. Un tableau des sprints
exécutés est présenté en annexe 8. L’exécution du sprint est la phase qui permet de réaliser les
tâches et les incréments de fonctionnalités. Le sprint exécution est accompagné chaque jour par
un petit évènement intitulé le daily SCRUM qui est une réunion d’environ quinze minutes où
chaque membre de l’équipe communique ce qu’il a fait la veille, ce qu’il doit faire aujourd’hui
et les blocages qu’il a rencontré. Le sprint se termine par une démonstration de ce qui a été
achevé, et la présentation d’un incrément potentiellement intégrable. Avant de démarrer un
nouveau sprint, l'équipe réalise un sprint retrospective qui est une revue méthodologique qui
permet d’identifier les améliorations à apporter aux prochains sprints.

Afin de mieux organiser notre démarche SCRUM, nous avons choisi d’utiliser le site web Trello
qui offre un service gratuit et souple, et un moyen visuel en ligne pour l’organisation de projet
avec une méthodologie agile. Nous avons créé les différents éléments de la méthodologie
SCRUM adapté à nos objectifs, et nous avons veillé à respecter leur bonne application tout au
long du projet. La figure 9 illustre l’interface conçue pour l’organisation de notre avancement
au projet :
Figure 9 : plateforme SCRUM
Conclusion :
A travers ce chapitre, nous avons essayé de vous mettre dans le cadre général où nos
missions de stage ont été réalisées, notamment, le contexte académique et professionnel, les
objectifs et nos missions, et puis, nous avons présenté la partie de management du projet où
nous avons défini les acteurs et l’approche avec laquelle est mené un tel travail, et après nous
avons élaboré une charte du projet et une étude AMDEC, tout en visant le respect des délais
fixés dans le planning prévisionnel.

Chapitre 2 : Environnements SAP et étude de l’existant
Chapitre 2 : Environnements SAP et étude de

l’existant
Environnements SAP et étude de l’existant

La bonne maitrise du processus achat requiert une
solution stable, agile mais surtout compatible au
secteur d’activité. Il est donc nécessaire de bien
connaître les différentes fonctionnalités de chaque
solution potentielle et mieux cerner son périmètre
fonctionnel. Tel est la finalité de ce chapitre, où
nous exposons globalement les solutions adéquates
à notre projet. Nous allons mettre la lumière sur le
module MM de SAP ERP, nous accordons plus
d’intérêt à la solution ARIBA procurement et SAP
SRM qui constituent les solutions centrales de notre
projet de fin d’études.
Plan
- SAP ECC
- SAP Ariba
- SAP SRM
- Etude de l’existant

1. Présentation de SAP ERP :
Avant de présenter SAP ERP, il est primordial de le situer dans le contexte de notre projet.
Cette solution est le fondement de nos connaissances en système d’information car sans la
compréhension et la maîtrise de l’ERP il est difficile de s’ouvrir sur les autres solutions qui en
dérivent. Dans notre projet, nous avons à priori commencé à nous former en SAP ERP afin de
mieux appréhender les bases de ce système, qui nous ont épaulé à capturer les concepts des
autres solutions.
1.1. Définition de l’ERP :
Les ERP sont des progiciels paramétrables, modulaires, intégrés et qui ont pour objectif de
mettre en réseau, par une base de données unique, l’ensemble des données relatives aux
fonctions de l’entreprise (comptabilité, communication, ressources humaines, marketing, etc.).
Un ERP permet de gérer l'ensemble des processus opérationnels d'une entreprise, en intégrant
l'ensemble de ses fonctions.
Cette notion a fait émerger l’idée que l’ERP pouvait être la colonne vertébrale du système
d’informations de l’entreprise. C’est pourquoi de nombreux éditeurs de logiciels ERP offrent
des solutions ERP clés en main, qui couvrent tous les domaines de l’entreprise.
Dans un tel système, la redondance des données entre départements n’existe plus;
l’information étant disponible pour tous en temps réel, une meilleure coordination interservices
devient possible et prend moins de temps ce qui améliore la productivité.
Tous ces avantages expliquent pourquoi de plus en plus d’entreprises décident d’utiliser les
ERP. Dans ce marché, SAP est le progiciel le plus utilisé à l’heure actuelle.
1.2. Présentation de SAP :
SAP (en anglais Systems, Applications and Products in data processings) est un système qui
intègre les différentes fonctions de l'entreprise (comptabilité, finances, production,
approvisionnement, marketing, ressources humaines, qualité, maintenance, etc.). Tous les
processus sont reliés entre eux par l'utilisation d'un système d'information centralisé sur la base
d'une configuration client/serveur. Il est fondé par cinq anciens employés d’IBM en 1972.

Aujourd’hui, SAP fournit des systèmes de gestion et de maintenance à des entreprises de

toutes tailles dans le monde entier. On dénombre plus de 140000 installations dans plus de 120
pays à travers le monde. Ce qui représente plus de 12 millions d’utilisateurs.
1.3. Les environnements de travail :
Sur le système SAP ECC intégré, nous distinguons 3 environnements du travail illustré sur la
figure 10, les consultants BC se chargent de créer ces environnements ainsi que définir les
utilisateurs pour y accéder.
Figure 10: Environnement de travail SAP
 Environnement de développement (DEV) : Au niveau de cette partie, les différents

paramétrages, solutions techniques et fonctionnelles sont mises en place afin de
répondre aux exigences client.
 Environnement de qualité (QUAL) : Dans cet environnement, les consultants
évaluent les modifications et leurs adéquations avec le besoin du client après la
transportation des différents paramétrages réalisés dans l’environnement DEV à l’aide
d’un ordre de transport (OT).
 Environnement de production (PROD) : Cet environnement est exploité pour les
activités métiers et l'enregistrement des données réelles du client. L'environnement
PROD représente le système final sous la charge du client, aucune modification, test ne
doit être appliquée sur ce système.
1.4. La gestion intégrée par SAP ECC :
L'une des raisons du succès de la solution SAP, est liée au fait qu'il soit possible de paramétrer
ce système afin de l'adapter aux besoins spécifiques d'une entreprise. Actuellement, SAP ERP
demeure la solution la plus flexible et la plus étendue pour couvrir tous les besoins des
entreprises.

Les modules fonctionnels, présentés dans la figure 11, peuvent être distingués en trois grandes
familles : logistique (modules MM, SD, PP, LE, QM, PM, CS, PS), gestion comptable (modules
FI, CO, PS) et ressources humaines (module HR).
Figure 11: Modules fonctionnelles de SAP
A noter, que les processus sur le système SAP sont commandés et gérés par des transactions
prédéfinies. Une transaction est un code composé de lettres et de chiffres qui permet de lancer
une fonctionnalité sur le système ; cette fonctionnalité peut être :
 Une tâche opérationnelle comme créer une commande de vente, modifier une
commande d’achat. (Exemple : Transaction ME21N créer une commande d’achat)
 Une tâche de gestion de référentiel : créer une fiche article, modifier une fiche client ou
une fiche fournisseur (Exemple : XK01 créer un fournisseur)
 Une tâche de reporting : lancer un état de stock par exemple (Exemple : MMBE Afficher
le stock d’un article)
1.5. Le module MM : Gestion des articles :
Le module MM figure parmi la panoplie des modules de la famille logistique sur SAP. Il permet
de gérer une grande partie du processus achat :
 Le calcul des besoins, des réapprovisionnements ;

 La gestion des demandes d’achat, commandes d’achat, contrats, etc. ;
 La gestion des stocks ;
 La gestion des emplacements et de l’inventaire ;
 Etc.

1.5.1. La structure organisationnelle :
Il est important de bien définir l’environnement logistique et financier de chaque unité

structurelle dans SAP. Pour cela ces structures se paramètrent au début du projet, et permettent
d’avoir des clés des tables pour accéder aux données. La figure 12 suivante représente une
arborescence de la structure organisationnelle sur SAP :
Société
Division
Magasin
Organisation achat
Groupe d’acheteurs
Figure 12: Structure organisationnelle du module MM
1.5.2. Les données de base du module MM :
Dans chaque module de SAP il existe une multitude de données primordiales, très
élémentaires, et indispensable à l’ensemble des transactions effectuées vis-à-vis un processus.
Dans le module MM en particulier, les données de bases sont énumérées ci-dessous :
 Fiche article : Une fiche article contient les données de gestion relatives à un
produit ou matériel donné.
 Fiche fournisseur : Une fiche fournisseur contient les données de gestion
relatives à un partenaire.
1.5.3. Le flux du processus achat sur MM :
Une approche processus est indispensable pour mieux comprendre le déroulement de la

fonction achat sur SAP MM. La figure 13 représente un schéma simplifié du processus achat.
Le processus achat intégrale d’AWB sera modélisé par la suite sur un schéma standard à
l’aide du logiciel Bizaji en utilisant le BPMN 2.0

Figure 13: Processus MM simplifié
1.6. Limites de la gestion des achats sur SAP ERP :
Le module MM de SAP permet une gestion pratique des achats, d’approvisionnement et de

stocks. Certes, la gestion de la relation fournisseur n’est pas assez développée comparée à
d’autres solutions qui proposent plusieurs fonctionnalités de rapprochement et de collaboration
avec les partenaires en amont de la chaîne logistique.
Prenons à titre d’exemple, un cas opérationnel -la gestion des appels d’offres sur SAP ERP-
qu’on détaillera par la suite : Après la création d’un appel d’offre sur SAP, l’acheteur passe à
la gestion de ce dernier en passant par la transaction ME47. Une fois que les offres sont
soumises par l’ensemble des participants (fournisseurs), l’acheteur passe à la comparaison des
offres en utilisant la transaction ME49. L’inconvénient est que la comparaison des offres sur
SAP se focalise uniquement sur l’aspect technique, c’est-à-dire seul le prix de l’offre est pris
en considération, ce qui ne représente qu’un seul critère de sélection parmi plusieurs qui
figurent parmi les pratiques de l’entreprise. Ceci dit, et surtout pour des achats stratégiques, une
multitude de critères (Prix, Délai, Capacité de production, respect de l’environnement…) sont
pris en considération, une grille de dépouillement est souvent utilisée pour affecter un score à
chaque critère, et ceci avant la réception des offres pour garantir une plus grande objectivité
lors du dépouillement. L’offre obtenant le meilleur score final est celle à qui on attribue le
marché. En ce qui concerne le secteur public, l’attribution du marché passe par la comparaison
de trois dossiers (administratif, financier et technique) ce qui demeure irréalisable sur SAP ERP.

Cet exemple ne représente qu’un petit aperçu des limites de la gestion de la relation
fournisseur sur SAP, en se projetant sur la perspective du global sourcing, les entreprises
souhaitent s’ouvrir sur de nouvelles opportunités géoéconomique, et établir de nouvelles
relations avec des fournisseurs qui proposent le produit ou le service le plus adéquats aux
attentes et exigences de l’acheteur et donc de toute la chaîne de valeur. En ce qui concerne les
enjeux de l’installation du système, les coûts de licences, la lourdeur d’intégration, la
complexité d’échange des différents documents électroniques et la difficulté de collaboration
font fuir les partenaires de l’entreprise.
Face à cette entrave, la société SAP s’est intéressée à d’autres solutions qui fournissent un
service et des fonctionnalités mieux adaptés appropriés à la gestion de la relation fournisseur.
Le regard de la société s’est fixé sur une société américaine nommée Ariba fondée en 1996, et
qui offre l’une des meilleurs solutions de commerce B2B.
SAP acheta Ariba en 2012 à 4.3 milliards de dollars.
2. La gestion des achats sur ARIBA :
Value Pass consulting, partenaire gold de SAP, adopte une stratégie de poursuite des
nouvelles technologies et évolutions en système d’information. Dans cette logique, Value Pass
a introduit l’intégration de SAP ARIBA parmi ses services. Notre projet de fin d’études
s’articule en premier lieu autour de la préparation d’un prototype de SAP ARIBA pour le client
AWB. La connaissance préalable de cette solution s’avère indispensable.
2.1 Présentation d’Ariba :
Ariba est le fondateur d’Ariba Network une place de marché virtuelle B2B où des acheteurs
et des fournisseurs peuvent se rencontrer et faire du commerce sur une plateforme unique basée
sur le cloud.
Cette plateforme représente une interface intuitive, simple et facile à utiliser pour toute
personne habituée à faire des achats en ligne. Au-delà de l’ergonomie de l’interface, Ariba
permet aux entreprises de découvrir, se connecter et collaborer au sein du plus large réseau
commercial au monde. Ce réseau offre aux vendeurs la possibilité de gérer leurs catalogues, de
répondre à des appels d’offres ou enchères et même de gérer leurs ventes et factures. D’autre
part, les acheteurs peuvent y trouver le meilleur fournisseur, lancer des enchères, suivre les
dépenses, gérer les contrats etc.
Quelques chiffres :
Selon les derniers chiffres communiqués par SAP, Ariba Network référencerait aujourd’hui :
 Plus d’un million et demi d’entreprises qui utilisent Ariba Network ;

 190 pays où la solution est opérationnelle ;
 Un volume de transactions annuel qui dépasse les 600 milliards de dollars ;
 Une prise en charge de 72 devises.
Dans les prochaines 24 heures, ces entreprises :
 Echangeront plus de 71 000 bons de commandes et plus de 224 000 factures ;

 Economiseront 82 millions de dollars en frais d’approvisionnement ;
 Effectueront des transactions commerciales à hauteur près de 2.5 millions de dollars.
2.2. Analyse SWOT :
L’analyse SWOT fait partie des outils qui contribuent à l'étude de la pertinence et de la
cohérence d'une action future. Nous avons établi cette analyse pour diagnostiquer les avantages
et inconvénients de la solution Ariba.
Figure 14: Analyse SWOT de la solution Ariba

2.3. Processus planifier, acheter et payer :
Le processus d’Ariba s’étend sur une phase de planification et une partie opérationnelle. Ariba
accompagne l’acheteur de la planification jusqu’au payement, le schéma suivant résume et
illustre le processus Planifier, Acheter, Payer.
Payement
•Conversion des données de

 Rationnaliser, enrichir, la commande d'achat Facture
Analyser
(conformité)
classifier les données
•Confirmer la Réception
Payer
Planifier Réception
•Recherche de Status
Decouvrir •Date d'expédition et de livraison
fournisseurs sur le
réseau
•Consulter Profil,
Commande
Enregistrer questions, certifications
du fournisseur
Planifier
•KPI et reporting du Validation
Qualité
fournisseur
Acheter
RFx Demande
Contrat
Phase de planification Phase opérationnelle
Figure 15: Le Processus Achat intégral sur Ariba
2.4. Ariba Cloud Procurement Menu :
Après l’identification du périmètre fonctionnel, Ariba propose une panoplie de scénarios

d’intégration qui répond au besoin du client. Il existe 4 outils qui constituent la solution d’Ariba
sur le Cloud :
 Purchase tool : outil qui permet la gestion des documents achats, appels d’offres…
 Catalog interface : Interface qui présente les catalogues des différents fournisseurs ;
 Accounts payable : Outil qui permet la gestion financière des processus métier ;
 Electronic network : Réseau Ariba qui englobe tous les utilisateurs du système.

Au final, on se projette dans l’un des 5 scénarios de la figure 16 suivante :
Figure 16 : Scénario d'intégration d'Ariba
Remarque :
Le Réseau « Marcketplace » en ligne, est présent dans tous les scénarios car sans lui aucune
solution ne peut être fonctionnelle. Le client peut utiliser uniquement cette solution et gérer
toutes les autres activités sur son ERP (scénario 5).
2.5. Classification des solutions Ariba :
Il existe une classification des solutions Ariba selon la consécution du flux du processus
achat. Cette classification s’organise sur trois niveaux :
 Up Stream : Solutions en amont du processus qui visent à identifier les fournisseurs et

gérer les contrats avec eux.
 Down Stream : Solutions en aval du processus et qui gèrent la partie opérationnelle de
l’approvisionnement jusqu’au paiement.
 Ancillary : Solutions auxiliaires du processus qui soutiennent les autres solutions.
Le tableau 5 présenté dans la page suivante représente une classification de ces solutions, et
comprend une courte description de chaque solution.

Flux Solution Description

Ariba supplier information Permet de gérer l’ensemble des informations propre au
Management fournisseur
Upstream
Ariba supplier performance Permet d’évaluer la performance des fournisseurs à

Management l’aide de tableaux de bord et de reporting
Ariba sourcing Permet d’identifier et de séléctionner les fournisseurs
Ariba Contract Management Permet une gestion globale des contrats
Ariba Contract Compliance Permet de contrôler les dépenses générées et leur
conformité aux contrats
Ariba P2P Gestion de l’achat de l’approvisionnement au paiement
Invoice and P/O Une structure qui permet à l’ERP de se connecter à
Automation Ariba Network
Downstream
Ariba Invoice Pro Solution conçue pour gérer les workflows des factures
à payer et traiter les exceptions
Invoice conversion Services Service qui permet de convertir les factures papiers à
un format électronique
Ariba Procurement Content Solution pour l’habilitation et la maintenance des
catalogues fournisseurs
Fieldglass Solution pour gérer le capital humain
Supplier Enablement Permet de se connecter électroniquement à des
fournisseurs (EDI, XML, EXML, Web forms.)
Ancillary
Ariba Discount Pro Une plateforme de remise dynamique pour le

payement à l’avance.
Ariba Spend visibility Permet d’analyser les différentes dépenses
Tableau 5: Classification des solutions Ariba

A travers la panoplie des solutions et des fonctionnalités qu’elle propose, Ariba se positionne
comme leader des solutions d’e-procurement. Cependant, elle demeure l’évolution sur le cloud
des solutions de gestion des achats qui dominent le marché et qui ont prouvé leur efficacité et
performance dans maints projets. SAP SRM a déjà été implémenté chez le groupe Al Omrane
par Value Pass et présente une solution robuste qui peut aussi répondre au besoin d’AWB.

3 .SAP SRM :
3.1. Présentation de SRM
Le terme « Supplier Relationship Management » désigne l'utilisation de technologies par une

entreprise afin d'améliorer le mécanisme d'approvisionnement auprès de ses fournisseurs.
L'objectif de SRM est de permettre à une entreprise de maitriser les processus métier,
d'améliorer la communication avec ses différents fournisseurs, et d'avoir une meilleure
connaissance de chacun d'entre eux afin de mieux identifier les fournisseurs stratégiques et
améliorer sa capacité de négociation. A l'inverse, il s'agit également de faire en sorte que les
fournisseurs connaissent mieux le cœur de métier de l'entreprise et ses différents produits afin
d'adapter leur prestation et anticiper leur besoin.
SRM permet de générer des économies durables, d'assurer la conformité des contrats et un
retour sur investissement assuré. Les éditeurs de solutions SRM définissent généralement un
processus en cinq grandes étapes : la conception collaborative, le sourcing, la sélection des
fournisseurs, la négociation et l’évaluation des performances du fournisseur.
3.2. La solution SAP SRM :
Cette offre s’appuie principalement sur la solution SAP Supplier Relationship Management et
le portail SRM. Elle intègre des fonctionnalités dédiées aux processus e-sourcing pour la gestion
achats, de traitement des appels d’offres, des enchères et la relation avec le fournisseur.
Elle comporte également des fonctionnalités liées à la :
• Pré-qualification et homologation fournisseurs ;
• Collaboration avec les fournisseurs.
• Gestion des contrats ;
• Gestion des rounds de négociations ;
• Evaluation de la performance fournisseur
Ces fonctionnalités couvrent la quasi-totalité du besoin client, ce sont des fonctionnalités en

interdépendance et permettent de contourner l’intégralité du processus achat.

3.3. Cartographie de la solution SRM :
La solution SRM nécessite une interaction étroite entre plusieurs fonctionnalités pour offrir
un modèle cohérent et structuré de gestion des achats. Les constituants de ce modèle sont
présentés dans un schéma en bloc suivant une structure verticale qui définit les différents
éléments en interactions et leur place au cœur du processus achat. Horizontalement, la figure
17 représente une décomposition fonctionnelle des différents blocs principaux.
Figure 17: Cartographie de la solution SRM
3.4. Scénarios de déploiement SAP SRM :
Le système SAP SRM peut s’intégrer avec SAP ERP, comme il peut s’intégrer avec un
système backend autre que SAP. SAP SRM supporte l’intégration avec tout type de système
backend (planification, comptabilité...) suivant quatre types de scénarios de déploiement.
Chaque scénario couvre un périmètre fonctionnel bien déterminé adapté au modèle de
l’architecture technique et fonctionnelle du client. Ces scénarios sont présentés en annexe 9.
3.4.1. Applicabilité du scénario classique étendu :
Après une étude de l’existant qui sera plus détaillée dans ce chapitre, nous avons pu se
positionner par rapport au scénario le mieux adapté à Attijari Wafabank. Le scénario classique
étendu permet une intégration avec le paysage applicatif d’AWB. Il est applicable pour les
clients qui ont un système backend puissant, et dont les acheteurs ne veulent pas utiliser
multiples systèmes et souhaitent bénéficier des fonctionnalités de gestion d’achat sophistiqués
proposées par SAP SRM.

3.4.2. Processus du scénario classique étendu :
Le flux du processus achat est présenté sur la figure 18, un acheteur déclenche le processus
par la consultation d’un catalogue et la création d’un panier sur SAP SRM. Une fois le panier
validé suite à une stratégie de validation, l’acheteur s’engage à lancer un appel d’offre qui est
transféré au portail fournisseur à l’aide du middleware SAP Process Integration. Le fournisseur
peut accéder directement au portail et répondre à l’offre. Une copie des réponses est envoyée
du portail à SAP SRM par la couche PI pour permettre à l’acheteur d’adjudiquer l’offre. Le
processus se finalise par une création d’une commande d’achat en référence à l’appel d’offre
qui sera copié sur le système backend.
FIREWALL
ERP SAP SRM PI SAP SRM
Acheteur Supplier
Portal
Demande d’achat Panier
Sourcing Cockpit
Création Appel AO copie

d’Offre
Copie des Réponses

réponses sur les sur les offres
offres
Adjudication de
l’offre
Commande Commande Confirmation

d’achat / Contrat d’achat / Contrat de la
commande
Entrée de Entrée de Avis

marchandise marchandise préalable
d’expédition
Création de Création de
facture facture
Figure 18: Processus du flux classique étendu

3.5. Comparaison entre SRM et Ariba :
Le tableau 6 pour but de souligner les différents contrastes entre SAP Ariba et SAP SRM, et
représente une comparaison non exhaustive des deux systèmes. La question du choix du
système le plus adéquat pour AWB sera traité dans le chapitre 3.
SAP SRM SAP Ariba

la gestion des données s'effectue via LSMW La gestion des données ainsi que le
processus d'approbation s'effectue via le
chargement des documents CSV.
Coûts du matériel et de la maintenance Il s'agit d'une solution basée sur le cloud,

aucun coût sur la maintenance ou sur le
matériel n’est nécessaire.
Différents scénarios sont disponibles: Il existe cinq scénarios d’intégration de SAP

Classique, Etendu, Standalone Ariba avec les autres systèmes backend.
le transfert des CA et La réception des Le transfert s'effectue par l'exécution d'un

articles au back end ERP s'effectue en temps scénario, ce dernier doit être programmé
réel pour être exécuté périodiquement. Les
données ne sont pas transférées en temps
réel.
Solution on premise Solution Saas (on demand)
Tableau 6: Comparaison de SAP Ariba et SAP SRM
Après avoir présenté les solutions et outils de travail utilisés dans ce projet, le lecteur dispose à
présent d’une vue d’ensemble des prérequis indispensables à la compréhension de notre travail
réalisé. Mais avant de se projeter dans cette perspective, nous présentons dans la partie qui suit
l’analyse de l’existant. Cela a pour objectif, en premier lieu, d’identifier l’état actuel du projet
c’est-à-dire le ‘As Is’, ou la représentation de la situation présente. En second lieu, cette analyse
nous permettra d’identifier la situation attendue à l’issu de ce projet, ou l’état futur c’est-à-dire
le ‘To Be’. Le modèle ‘Should Be’ est une représentation d’une situation envisagée à long terme
et sera présenté dans la partie bilan et perspectives.

4. Etude de l’existant :
4.1. Le As Is :
4.1.1. Paysage applicatif d’AWB :
Attijari Wafa Bank gère ses processus financiers à l’aide d’un système d’information développé
par la société Infor. SmartStream représente le système backend d’AWB auquel on est amené
à intégrer notre solution SAP de gestion des achats.
La solution Infor FMS SmartStream assure la gestion de tous les processus financiers de
l’entreprise, des fonctions de plans budgétaires évolutifs, pour aller jusqu’à l’établissement d’un
système précis et efficace de facturation. La solution inclut également les créances à recevoir,
aussi bien pour les entreprises locales qu’internationales. Cette solution assure une gestion
rapide et efficace des périodes de clôture, des processus de paiements centralisés et des flux de
données synchronisés en provenance de tous les grands livres auxiliaires via un grand livre
général, tout en assurant un contrôle de caisse efficace, la gestion des devises et en apportant
des outils puissants d’analyse de l’information et de reporting.
La solution est composée des modules suivants :
 Dettes fournisseurs - tous les processus créditeurs.

 Grand livre : centralisation de toutes les informations financières de l'entreprise.
 Affectations : attributions des coûts et des recettes à une ou plusieurs divisions de
l'entreprise.
 Gestion des immobilisations : simplifie la gestion des actifs depuis leur acquisition
jusqu’à leur sortie des livres.
 Chaîne d’approvisionnement : gestion des mouvements internes d’articles au sein de
l’entreprise.
 Achats : envoi des demandes, suivi de la chaine de validation et création automatique
des ordres d’achat.
 Projets : gestion des projets internes liés au capital, aux frais ou aux deux.
 Contrôle de fonds : suivi et contrôle des fonds.
 Applications Web : Infor FMS SmartStream offre également plusieurs modules Web
pour gérer, par exemple, les demandes d’achat, les recettes, les règlements, les
validations de factures, les ordres d’achat et les validations des entrées dans le journal.

4.1.2. Etat des lieux du projet :
Nous avons abordé le projet en début de phase de conception, ceci dit, la phase de
préparation initiale a été déjà achevé avant de rejoindre l’équipe MM de Value Pass. L’équipe
du projet avait déjà mené plusieurs réunions avec le client au cours de la préparation initiale
ayant pour objectif l’élaboration d’un plan détaillé du projet. Lors de la phase de préparation
l’équipe Value Pass a proposé la solution Ariba qui peut potentiellement répondre au besoin
exprimé par AWB. A la fin de la phase de préparation et avant le lancement du projet, un
environnement de test sur Ariba a été mis en place afin d’y construire le design de la solution
qui va à l’encontre des fonctionnalités demandées par le client (Annexe). Nous avons été
affectés à ce projet exactement après l’approbation du client à la préparation d’une
démonstration future des solutions Ariba. Pratiquement, ce n’est qu’une seule consultante chez
Value Pass qui avait un savoir et des connaissances sur Ariba, celle-ci nous a fait passer les
différentes consignes. A ce niveau, nous avons été amenés à bien comprendre le fonctionnement
de cette solution avant de préparer le prototype.
4.1.3. La situation actuelle de la gestion des achats sur AWB:
AWB gère ses achats de façon classique à l’aide de commandes éparpillés, sur des mails, faxes
ou des fois mêmes uniquement par appel téléphonique. Le problème de traçabilité des
commandes et d’analyse des dépenses s’imposait. Quant aux appels d’offres, ils ne pouvaient
atteindre tous les fournisseurs potentielles mais se limitaient uniquement à ceux ayant déjà
collaboré avec AWB. Cela réduit la compétitivité et diminue la concurrence et donc
représentait un manque à gagner. Cela vaut de même pour les contrats, dont seuls les plus avertis
des fournisseurs pouvaient en profiter.
4.2. Le To Be :
Le client souhaite avoir une solution qui gère l’intégralité de son processus achat. La seule
partie qui sera géré sur son ancien système d’information est la gestion des factures. AWB a
s’est engagé à investir dans ce projet de refonte du système d’information, pour réaliser des
économies d’échelle, en rationalisant leur achat, auprès des fournisseurs qui offrent les
meilleurs services. Leur cible est une intégration complète entre leur système d’information et
une solution SAP de gestion des achats, afin d’améliorer leurs achats au sein des différentes
filiales, bureaux, agences commerciales …en bénéficiant des meilleurs pratiques SAP.

Traduction du besoin client en fonctionnalités système :
Pour le client, les solutions SAP sont souvent une boîte noire dont il ignore le contenu, c’est
pour cette raison qu’AWB a exprimé son besoin sous forme de fonctionnalités en vrac. Notre
travail à ce niveau, était de traduire l’ensemble des fonctionnalités demandées à des
fonctionnalités exécutable et gérable par les solutions SAP de gestion des achats, pour mieux
cadrer le ‘To Be’. Inspirés des fonctionnalités demandés sur l’annexe 1, Le tableau 7 représente
les différentes fonctionnalités proposées catégorisées en périmètre fonctionnel :
Périmètre Fonctionnalités
Création d'un appel d'offre en référence d'un panier
Traitement de l'appel d'offre
Publication de l'appel d'offre
Appel d'offre Réponse des fournisseurs sur l'appel d'offre
Donner la possibilité aux utilisateurs de prolonger les périodes de réponses aux
appels d’offres
Comparaison des offres (Administratif/ technique / Financier)
Adjudication de l'offre
Création d'une enchère
Traitement de l'enchère
Publication de l'enchère
Enchères Réponse des fournisseurs sur l'enchère
Comparaison des réponses fournisseurs
Adjudication de l'offre de l'enchère
Gestion et réception des offres spontanées
Contrat Création d’un contrat à partir d’une offre
Gestion des rounds de négociations
Homologation Homologation et Présélection des fournisseurs
Fournisseur Qualification des fournisseurs
Suivre l'activité des fournisseurs consultés : permettre d’avoir une traçabilité sur
Reporting tous les échanges effectués avec les prestataires (dates, échanges de documents,
temps de réponse des fournisseurs…)
Pour chaque AO, calcul des économies et performances réalisées
Tableau 7: Fonctionnalités demandées par le client

Conclusion :
Dans ce chapitre nous avons expliqué les concepts de base liés au projet, à savoir le module de
gestion des articles MM, la solution SAP Ariba et la solution de gestion des relations
fournisseurs SAP SRM. Nous avons aussi identifié les avantages et inconvénients des
différentes solutions proposé à l’aide de comparaison, d’analyse SWOT et de synthèse des
limitations, afin de cerner la solution qui répond au mieux aux exigences d’Attijari Wafa Bank.
L’analyse de l’existant a aussi été traitée dans ce chapitre pour élucider l’état actuel du projet,
et l’état futur. Le chapitre suivant développera davantage le travail concrètement réalisé.

Chapitre 3 : Design de la solution de
gestion des achats
Design de la solution de gestion des achats
Les compétences d’un consultant se reflètent dans

son savoir-faire à traduire un besoin en un modèle
fonctionnel cohérent au sein du système
d’information. Dans cette logique, ce chapitre est
consacré au travail réalisé durant notre projet de
fin d’études et qui se focalise en premier lieu, sur le
déroulement du flux d’achat sur SAP Ariba. Après
la transition de SAP Ariba à SAP SRM, nous avons
abordé en second lieu, la conception fonctionnelle
et le prototypage de la solution d’autre part, ainsi
que le paramétrage et la réalisation de la solution
finale.
Plan :
- Déroulement du flux d’Achat sur Ariba
- Conception de la solution SAP SRM
- Paramétrage de la solution SAP SRM

Chapitre 3 : Design de la solution de gestion des achats
En adéquation avec notre proposition au client, pour démontrer la solution Ariba, cette partie
a été consacré au déroulement du flux d’achat sur SAP Ariba de bout en bout. Nous avons suivi
le modèle du processus détaillé sur la figure 15, en commençant par la découverte du
fournisseur, en d’autres terme sa qualification, et finissant par la réception de marchandises en
passant par les projets de sourcing, contrat, demande d’achat, commande d’achat . On a clôturé
cette partie par une présentation du reporting sur SAP Ariba qui correspond à l’analyse sur la
phase de planification de la même figure.
Partie 1 : Déroulement du flux du processus achat sur la solution

Ariba pré-packagée
Avant de présenter les différents éléments (qualification, appel d’offres, enchère, contrat)
intervenants dans le processus achat, nous devons clarifier deux points communs concernant la
création de ces éléments. (voir annexe)
De plus, nous avons prédéfinis, parmi les différents modèles proposés par Ariba, un modèle de
Template pour chaque élément (qualification fournisseur, appel d’offre, enchère, contrat) du
processus achat. Ces modules ont été conçus par Ariba pour se rapprocher le plus possible du
besoin client. L’objectif est d’éviter d’imposer au client un surplus de fonctionnalités, on
cherche à couvrir uniquement ce qui est demandé. Ces Templates contiennent les cinq éléments
suivant :
 Une présentation générale du projet ;

 Un document du projet (une enquête de qualification dans le cas ci-dessous) ;
 Les tâches à accomplir ;
 L’équipe du projet ;
 Les différents messages de l’évènement ;
 L’historique des actions effectuées ;
1. Projet de sourcing :
Un projet de sourcing permet d’évaluer la qualification du fournisseur, publier un appel d’offre,

une demande d’information ou des enchères. Le point fort d’Ariba est qu’un projet sourcing ne
se limite pas aux fournisseurs crées sur la base de donnée (comme sur SAP ERP), mais
l’acheteur peut publier un appel d’offre par exemple sous forme de post sur une plateforme du
réseau Ariba nommé Ariba Discovery. Cette plateforme réunis plus d’un million de

fournisseurs qui peuvent répondre à cette opportunité. Dans notre cas, notre environnement de
test ne nous permet pas de faire des publications sur Ariba Discovery. On va se contenter de
gérer des projets sourcing par rapport aux fournisseurs créés sur notre base de donnés.
1.2. Projet de qualification fournisseur :
Un projet de qualification fournisseur permet de mener une investigation auprès d’un

fournisseur potentiel, en lui posant différentes questions pertinentes. Dans ce volet, on va
utiliser le modèle ‘Demo Supplier Qualification Management Template’ fournis par Ariba, car
il est en adéquation avec les spécificités d’AWB pour la qualification fournisseur.
Figure 19: Projet de qualification fournisseur

Afin de bien mener un projet de qualification il faut valider deux tâches obligatoires :
 La création d’une équipe de projet

 Traiter l’enquête de qualification et la publier
Pour la publication d’un évènement enquête pour la qualification fournisseur, on est tenu à :
 Définir les règles : Ces règles régissent chaque aspect du fonctionnement de

l'événement. Par exemple, les règles de minutages définissent la date/heure de
l’événement et sa durée.
 Inviter les participants : ce sont les fournisseurs potentiels.
 Préparer le contenu de l’évènement : il s’agit du noyau du projet de qualification, le
contenu correspond à un ensemble de questions ciblées.
Un poids peut être affecté à chaque question afin de mieux évaluer les réponses fournisseur.

La figure 20, dans la page suivante, présente un exemple de questionnaire que nous avons créé
avec pondération des questions.
Figure 20: Evaluation des questions

Après la réception des réponses fournisseurs Ariba calcule automatiquement la note de chaque
réponse. S’il s’agit d’une réponse qualitative, le responsable du projet de qualification note
manuellement les différentes réponses.
Le fournisseur reçoit l’invitation de participation aux différents événements de sourcing

automatiquement par e-mail lorsque l’évènement est publié. Pour y répondre, il accède à la
plateforme Ariba dédié aux fournisseurs où il retrouve tous les évènements auxquels il peut
participer.
Figure 21: évènements de sourcing

Le responsable de l’évènement peut prolonger le minutage, ce qui répond à la fonctionnalité

demandée par le client.
Figure 22: Minutage d'un événement de sourcing
Après l’évaluation des fournisseurs, l’équipe du projet décide quels sont les fournisseurs les
mieux placés pour nouer de nouvelles relations avec eux. Les fournisseurs choisis sont ajoutés
dans le système. A présent, ils peuvent participer à des événements de sourcing.
1.2. L’appel d’offre :
En réponse à la demande d’AWB, nous avons élaboré un modèle d’appel d’offre qui contient
trois volets : le dossier administratif, le dossier technique et le Pricing qui correspond au dossier
financier. On peut joindre à chaque volet des questions, des exigences ou des documents. La
figure 23 présente un exemple réduit d’un appel d’offre :
Figure 23: Exemple d'appel d'offre

Une fois l’appel d’offre publié, les fournisseurs concernés peuvent avoir une prévisualisation
du contenu. . Un compte à rebours en temps réel affiche le temps restant de prévisualisation et
de reponse de l’appel d’offre
Figure 24: Durée de prévisualisation et de réponse
Une fois que la date et l’heure de début de réponses est atteinte, les fournisseurs peuvent
commencer à soumettre des réponses à l’offre.
Figure 25: Réponse du fournisseur à l'appel d'offre

Selon son rôle au sein de l’équipe du projet sourcing, ce membre de l’équipe peut avoir une
vision en temps réel des différentes offres proposées par les fournisseurs. Comme sur la figure
22 il peut écourter, prolonger ou arrêter l’évènement. Une fois que l’évènement est terminé, les
membres de l’équipe peuvent comparer les offres. La comparaison se fait sur la base TCO (
Total Cost of ownership) qui correspond au coût total de l’article en ajoutant les frais
d’approches. Pour effectuer le choix final du fournisseur, l’équipe du projet sourcing s’organise
pour procéder à l’adjudication de la meilleure offre suivant des scénarios d’optimisation. Ces
scénarios sont sélectionnés par rapport à l’objectif final du projet de sourcing, ils peuvent être
optimisés par rapport au meilleur prix, la meilleure qualité le meilleur score.

Figure 26: Comparaison des offres et adjudication
1.3. L’enchère inversée :
L’enchère inversée permet de faire baisser les prix en augmentant la concurrence tout en
réduisant le temps de négociation. Sur Ariba, nous utilisons le modèle d’enchères inversé avec
coût total qui résulte de la superposition de plusieurs coûts (transport, emballages, assurance,
stockage, exploitation…).
En parfait adéquation avec la fonctionnalité de gestion des rounds de négociation exprimé par
AWB, des règles de minutage sont définis pour les lots (rounds) de dépôt de l’offre (durée
d’exécution, période de vérification, période de prolongation etc.)
Figure 27: lots de négociation
Pour lancer un évènement projet de sourcing de type enchère inversé il faut bien définir les
règles de dépôt d’offre (décrément d’offre, protéger l’offre en tête avec une zone de protection
supérieur et inférieur). La figure 28 illustre la plateforme fournisseur pour la participation à
l’enchère.

Figure 28: Réponse à l'enchère
Parallèlement aux réponses des fournisseurs, et comme dans le cas des appels d’offres, les
membres de l’équipe du projet de sourcing (selon les rôles autorisés) peuvent suivre l’enchère
en temps réel.
Figure 29: suivi et contrôle de l'enchère en temps réel:

2. Gestion des contrats :
Partout dans le monde, et quel que soit la stratégie d’achat adoptée par l’entreprise, la gestion
des contrats constitue un point clé pour la bonne maitrise du métier des achats ; dans ce sens,
SAP Ariba a mis en place une solution de gestion des contrats (Contract Management) qui
permet de créer, gérer et publier un projet de contrat avec une manière efficace et très pointue.
Dans cette partie, nous allons présenter le déroulement du flux de cette solution.
Après le choix d’espace du travail contrat d’approvisionnement, on doit remplir toutes les
données en relation avec notre contrat. A savoir, une description pour l’espace, le fournisseur
avec lequel on souhaite signer un contrat d’approvisionnement.
Une fois que la création de l’espace du travail contrat est faite, on reçoit un récapitulatif résumé
pour avoir une image globale sur l’avancement dans la création de l’espace, et ça donne aussi,
une visibilité sur la gestion des tâches et leurs accomplissements.
Comme déjà mentionné, chaque processus sur Ariba est géré par une template personnalisée au
préalable qui cadre les étapes du processus. Nous avons travaillé avec la template ‘Demo
contract management’ pour la gestion des contrats, et que nous avons adoptée pour le
déroulement du flux. Les trois grandes étapes du processus sont :
 Initiation et création.
 Négociation et revue.
 Validation.
Chaque étape contient des tâches à réaliser, la figure suivante met en évidence l’ensemble de
ces tâches, et les deux livrables l’accord et le contrat final.
Figure 30: Processus de gestion d'un projet contrat

Description du processus création du contrat :
Dans la première étape, nous avons une seule tâche à effectuer, c’est celle de mise à jour des
membres de l’équipe, généralement constituée de groupe d’acheteurs et les approbateurs, afin
qu’ils fassent une revue des articles cités dans l’accord dans la deuxième étape négociation et
revue ; après cette tâche, une version de l’accord cadre est envoyée au fournisseur pour
négociation, à noter, que Ariba Contract Management donne la possibilité de faire des rounds
de négociation pour la bonne collaboration entre client et fournisseur. Et finalement, on a l’étape
de validation, qui fait appel à une procédure d’approbation pour que le contrat final soit généré
pour la signature.
La génération et la synchronisation des livrables sur SAP Ariba sont gérées par la technologie
DFS, qui est un ensemble de services client et serveur permettant de rassembler différents
partages de fichiers à un endroit unique.
3. Processus P2O :
Dans la partie opérationnelle du flux de SAP Ariba, nous avons le flux complet d’achat, partant
de la demande d’achat jusqu’au paiement de la facture, ce qu’on appelle le processus P2P, pour
notre cas, et à travers l’étude du besoin de notre client faite préalablement, nous avons travaillé
sur le flux d’achat jusqu’à la réception de marchandises, ce qu’on note P2O (procure to order).
On rappelle que la partie gestion des factures et paiement est gérée le système backend Smart
Stream du client.
La modélisation du processus d’achat P2O adopté par Ariba est décrite en annexe 11.
Parmi les outils qui ont prouvé la performance de SAP Ariba, on cite son E-catalogue
permettant de regrouper un ensemble des articles de plusieurs fournisseurs ; à cet effet, à chaque
expression du besoin l’acheteur peut consulter le catalogue pour faire passer des demandes
d’achats.
Dans la page suivante, la figure 33 on montre un exemple de test d’articles avec lequel on a
déroulé le flux, qui sont des articles de type ‘Moyen généraux’ pour AWB

Figure 31: Exemple de catalogue de SAP Ariba

Après le choix de l’article désiré, on reçoit une notification pour procéder à la validation, qui
comprend la référence de la demande d’achat (PR6695) et les articles choisis du catalogue.
Figure 32: Ajout d'articles au panier

Dans chaque processus d’achat, on utilise ce qu’on appelle les stratégies d’approbation. Sur la
base du type d’article commandé, de la quantité ou la valeur totale de la demande, un schéma
d’approbation se déclenche, comme illustré sur la figure 35.
Figure 33: Procédure d'approbation d'une DA

Après l’approbation de la demande d’achat, celle-ci se convertit automatiquement en

commande d’achat, après vérification budgétaire.
Figure 34: Commande d'achat
A ce niveau, la commande s’envoie au fournisseur sur Ariba Supplier pour procéder à sa

confirmation. Ce n’est qu’après la confirmation du fournisseur, qu’on peut passer à la réception
de marchandises.
Figure 35: Réception de marchandises

La réception de marchandises est un flux, qui fait appel à un agent de magasin pour remplir un
tableau qui garde la traçabilité des articles acceptés et rejetés. On présente ci-après, dans la
figure 36, les étapes de réception de marchandises.
Figure 36: Etapes de réception de marchandises

4. Reporting :
Pour répondre au besoin en matière reporting d’AWB, nous avons configuré des modèles de
reporting en s’inspirant des modèles pré packagés d’Ariba. Pour mettre en œuvre un report, il
passer différente configurations :
1. Identifier la source des données (Bon de commande, clause de contrat…

2. Définir les données de base, les champs de ligne, de colonne et les champs de page
Figure 37: Champs d'un report
3. Configurer le tableau croisé dynamique

4. Choisir le type de graphique souhaité (Camembert, Beignet, histogramme…)
La figure suivante représente un exemple de report de type colonne du montant total des
commandes par fournisseur :
Figure 38: Report montant total commande par fournisseur

Transition de SAP Ariba à SAP SRM :
Nous avons présenté dans la partie précédente, notre mission durant la première période de
stage, qui avait un objectif principal, la préparation d’un prototype v0 pour la nouvelle solution
SAP Ariba. Nous avons essayé d’exposer les points forts et les avantages de la solution que
vient d’acquérir le leader mondial de transformation digital SAP GE ; notamment, la flexibilité
et l’agilité dans la gestion du métier achat, dont on remarque en évidence les bonnes pratiques
adoptées par SAP.
L’équipe MM a démontré le prototype v0 au comité de pilotage du projet, qui a jugé

surdimensionné le niveau des fonctionnalités qu’offre SAP Ariba. Sur ce, le comité a décidé
d’implémenter une autre solution pour la gestion des achats, qui est bel et bien SAP SRM.
SAP SRM a prouvé sa performance à travers ses diverses implémentations dans le monde, et
spécialement au Maroc, à titre d’exemple, Groupe Al Omrane, qui ont déjà commencé à
travailler avec. SRM reste le plus adéquat au contexte marocain dans ce moment, vu la
résistance au changement vis-à-vis la grande évolution qu’a fait Ariba en se basant sur le Cloud.
Un aspect important du cloud est la notion d'interconnexion avec divers matériels qui rend
difficile et nécessaire la sécurisation de ces environnements. Un problème de sécurité dans une
plateforme sur le cloud peut engendrer une perte économique mais également une mauvaise
réputation si toutefois cette plateforme est orientée grand public comme le cas d’Attijari Wafa
Bank. Les problèmes de sécurité du cloud sont la cause du retard de l'adoption massive de cette
nouvelle solution, à titre d’exemple, un exemple que nous avons vécu dernièrement, l’attaque
‘WannaCry Ransomware 2017’ qu’a mobilisé les grands acteurs du domaine de sécurité
informatique à l’échelle mondiale. Nous pouvons rajouter à cela, la stratégie du calcul de coût
de licence est différente par rapport à SRM ou aux autres solutions SAP, Ariba fait introduire
d’une part, le facteur des commandes passées par l’entreprise et calcule le coût en fonction de
quantité des articles et du coût total de la commande, ce qui rend son utilisation un peu coûteuse,
et d’autre part, demande un engagement de la part des fournisseurs qui profitent de la plus
grande réseau des fournisseurs dans le monde Ariba Network, mais qui devront payer à leur
tour sur chaque document géré (bon de commande, etc.).
Après la décision du comité de pilotage, nous avons entamé la phase de conception et la phase
réalisation de projet d’implémentation de SAP SRM pour répondre au mieux aux exigences et
besoins exprimés de la part du notre client.

Partie 2 : Conception et réalisation de SAP SRM
Notre projet adopte la démarche ASAP Focus dédiée pour la mise en œuvre et prototypage des
SI, nous avons contribué dans les deux phases du projet : conception et réalisation. Parmi les
entrées de la phase conception, on retrouve l’installation du système et l’activation des
préconfigurés. Puis, on entame la phase de conception et prototype, pour faire l’étude détaillée
des processus, et rédiger les livrables de cette étape ; et par la suite, on commence la phase de
réalisation et paramétrage.
1. Lancement de la conception :
1.1. Installation du système de SAP SRM et activation de préconfigurés :
Nous avons mentionné préalablement au chapitre 2, que n’importe quel système SAP passe par
trois environnements, un premier de développement, le deuxième pour la qualité et tests, et le
troisième pour la production.
L’équipe technique Value Pass assure l’installation du système dans l’environnement

développement, et l’équipe logistique s’occupe de l’activation des fonctionnalités
préconfigurées de SAP SRM.
La figure suivante illustre les propriétés du l’environnement DEV :
Figure 39 : Environnement AWB DEV

1.2. Modélisation du processus cible AWB :
La modélisation du processus visé est indispensable pour bien le comprendre, et mieux

appréhender les éléments qui y interagissent. Nous avons schématisé le processus fonctionnel
cible qu’AWB cherche à mettre en place. Une modélisation en BPMN plus détaillée est
présentée en annexe.
SmartStream SAP SRM PI SAP SRM

Supplier
Référentiels Portal
FIREWALL
Articles
Fournisseurs
Référentiels Fournisseurs
Fournisseurs
Homologation
fournisseur
Demande Panier
d'achat
Création d'un
appel Copie
RFP/enchère
d'offre/enchère
Comparaison Réponses
des réponses RFP/enchère
Sélection
fournisseur
Commande Confirmation
d'achat/Contrat
Copie entrée Entrée de

de ASN
marchandise marchandise
Facture
Figure 40 : schéma cible fonctionnel

2. Conception de SAP SRM :
La phase de conception consiste pour la maîtrise d'ouvrage AWB à exprimer son besoin à la
maîtrise d'œuvre Value Pass. Cette phase est essentielle car les documents qui en seront issus
permettront de paramétrer la solution dans l'outil et d'identifier les développements
(spécifiques, formulaires ...) ainsi que les interfaces avec d'autres éléments constituant le SI.
2.1. Définition des règles de gestion :
Les règles de gestion (ou règles de métier, « business rules » en anglais) sont des déclarations
de haut niveau structurées, qui permettent de contraindre, contrôler et influencer un aspect
du métier. Les règles métiers doivent être établies en fonction des besoins des partenaires et
des parties prenantes. La définition des grandes lignes des règles de gestion intervient dans la
phase d'alignement stratégique, au début du processus de développement des exigences.
L'objectif est de disposer de règles claires, c'est-à-dire non ambiguës et compréhensibles par
tout le monde, la méthode est de séparer la logique métier de la logique système.
La formalisation des règles de gestion nécessite un travail d’équipe soudé, car il est essentiel de
bien communiquer les différentes exigences client surtout que nous n’avons pas pu assister aux
réunions chez AWB. Pour ce faire, notre team leader nous a communiqué des fichiers Word et
Excel qui constituent les lignes directrices de notre formalisation des règles de gestion.
Nous avons pu définir les règles de gestion des données de bases (articles et fournisseurs) et
ceux de la réception de marchandise. Les autres règles de gestion ont été définies par les autres
membres de l’équipe MM.
Règle de gestion – type article :
 Un article appartient à un type d’article
 Les types d'articles sont différentiés par les tranches de numéros qui leur sont
affectés.
 L’article est défini par un code alphanumérique.
 Le numéro d’un article est attribué par le système automatiquement en interne

Code Désignation Tranche de numéro
ZFRB Fourniture de bureau 10000000-10999999
ZPST Prestations de service 11000000-11999999
ZMNG Moyens Généraux 20000000-20999999
ZHSE HSE 21000000-21999999
ZINV Investissement 22000000-22999999
ZMRK Marketing 23000000-23999999
ZPSI Prestation intellectuelles 30000000-30999999
Tableau 8 :Propriétés des types article
Règle de gestion fournisseur :
- Un fournisseur appartient à une catégorie fournisseur

- Une catégorie fournisseur représente sa localisation, sa contribution ou son statut.
Code Description Tranche de numéro

ZFLO Fournisseurs locaux 100000-199999
ZFET Fournisseurs étrangers 200000-299999
ZFOC Fournisseur occasionnel 300000-399999
ZFPR Personne physique 400000-499999
Tableau 9: Propriétés de gestion fournisseur
Règle de gestion de la réception :
 La réception se fait en référence au bon de commande (les postes du mouvement de

réception sont repris de la commande automatiquement) ;
 La réception se fait en un seul mouvement ;
 Un bon de réception peut être imprimé ;
 Une tolérance est activée par poste du bon de commande, mais le système ne permet
pas dépasser le montant total TTC du bon de commande.
 Réception des articles consommable non stocké (par exemple Fournitures de bureau) et
immobilisation.
 Une fois la réception est effectuée, un document de réception est créé automatiquement

 L’entrée marchandises se fait après la réception d’un avis préalable d’expédition ;

 Si les articles sont conformes on procède à la création de facture, sinon une réclamation
doit être envoyée au fournisseur.
2.2. Identification des processus à paramétrer :
Dans cette partie, nous avons identifié les processus métiers à paramétrer sur le système, tout
en répandant au mieux au besoin client que nous avons traduit en termes de fonctionnalités
système dans le tableau 7 chapitre 2.
Et donc, pour ce faire, nous allons paramétrer les processus suivants :
 Gestion des appels d’offres

 Gestion des enchères
 Gestion des contrats
 Auto-enregistrement des fournisseurs
 Qualification des fournisseurs
 Présélection fournisseur
 Reporting : Indicateurs des économies et performances réalisées
2.3. Rédaction des fiches de conception :
Dans cette étape du projet, nous avons eu l’occasion de contribuer à la rédaction des fiches de
conception, on distingue deux types de fiche de conception, à savoir fiche de conception
générale et détaillée, elles font l’objet des livrables de la phase de conception.
Généralement, les fiches de conception contiennent les parties suivantes :
 Description et enjeux
 Définitions
 Règles de gestion
 Impacts organisationnels
 Les points en suspense
 Liste de paramétrage
Nous avons travaillé avec l’équipe MM sur la rédaction de fiches de conception, spécialement,
la fiche article, fiche fournisseur, et fiche réception de marchandises.
Des figures des fiches de conception sont dans l’annexe 13.

3. Paramétrage et réalisation :
L’étape de paramétrage s’insère dans la phase de réalisation de la méthodologie ASAP

qu’adopte notre projet ; elle consiste à adapter le système SAP aux besoins du client et assurer
ses fonctionnalités demandées. En opposition au développement spécifique des fonctionnalités,
le paramétrage est inclus dans le standard SAP. Dans cette partie, nous allons présenter une
partie du paramétrage réalisé, à savoir : le paramétrage de live auction, de bon de réception,
d’auto-enregistrement, présélection, évaluation des fournisseurs et la gestion des contrats ; à
noter que les autres paramétrages nécessaires ont été réalisés de la part de l’équipe MM.
3.1. Paramétrage live auction cockpit :
Live auction cockpit est une plateforme d’enchère virtuelle, qui permet de gérer des enchères
inversés en temps réel. Avec deux interfaces, l’une dédié à l’acheteur et l’autre au fournisseur
Live auction cockpit s’intègre étroitement au processus d’achat de SAP SRM et permet de
réduire le temps global de traitement des offres fournisseurs.
Pour activer SAP live auction Cockpit on procède par le point de paramétrage suivant : IMG –
> SAP Supplier Relationship Management –> Supplier Collaboration –> Live Auction –
> Activate/Deactivate Live Auction on ABAP Server.
Figure 41 : Activation de live auction cockpit

Ensuite il faut définir le type de transaction, c’est-à-dire les différents types d’enchères qui
peuvent être géré par SAP live auction, pour ce faire, on procède à au point de paramétrage
suivent : IMG –> SAP Supplier Relationship Management –>SRM Server–>Cross-Application
Basic Settings –> Define Transaction Types.
Figure 42 : paramétrage de type d'enchères

Figure 43 : Définition des types d'enchères

Après le paramétrage, on a rencontré une erreur illustrée dans l’annexe 14 au niveau du
lancement de SAP live auction cockpit. Pour résoudre cette erreur nous avons implémenté la
note SAP 2075978. Une note SAP est un diagnostic qui définit les symptômes de l’erreur,
l’environnement où elle s’est produit, les étapes pour reproduire l’erreur, la cause de l’erreur et
la résolution sous forme de code ABAP.
Un exemple de test du live auction a été joint en annexe 14.
3.2. Paramétrage des catégories message – Bon de réception :
Le bon de réception est un document qui récapitule toutes les informations relatives au contenu
de la livraison, il représente l’un des documents achats de base. Pour pouvoir imprimer un bon
de réception il faut d’abord passer par les paramétrages suivant :
Figure 44 : paramétrage de bon de réception

La catégorie de message du bon de réception est WE01 qui est un standard SAP, A travers une
séquence d’accès on lie la catégorie message déjà définit (WE01) à un formulaire
ZMM_BON_RECEPTION, celui-ci est configuré par la suite à travers la transaction
SMARTFORMS avec la contribution de l’équipe BC, voir annexe 15.
Une fois que le chemin d’accès est défini, on passe à la transaction MN22 pour paramétrer les
conditions d’impression du bon de réception :

 L’unité de sortie : LP01

 Date et heure de l’envoi : Envoi via transaction spécifique à l’application
 Type de support : sortie imprimante
 Langue : Français
Figure 45 : définition des conditions d'impression
Un exemple d’un bon de réception est joint en annexe 15.
3.3. Paramétrage d’auto-enregistrement des fournisseurs :
Les fournisseurs peuvent s'enregistrer à l'aide d'un lien disponible dans la page d'accueil du
client. Lors de l'enregistrement, les fournisseurs s'affectent à un ou plusieurs types de produit.
L'acheteur peut définir des formulaires associés aux catégories de produit. Il peut également
définir des formulaires indépendants des types de produit et les affecter à une catégorie neutre
(catégorie fictive). Une fois qu'un fournisseur s'est enregistré, le système d'enregistrement lui
envoie un ou plusieurs formulaires. De cette façon, l’acheteur disposera, d'informations
supplémentaires détaillées sur les fournisseurs potentiels.
Pour l'acheteur, les fournisseurs qui interviennent via le processus d'enregistrement constituent
tous de nouveaux partenaires potentiels.
Nous avons paramétré cette fonctionnalité, en accédant au guide de référence avec la transaction
SPRO.

Figure 46 : Activation de service auto-enregistrement

Nous pouvons tester l’activation de ce service à travers la transaction SE80, et en renseignant
le nom du service qui assure cette fonctionnalité, qui est : ROS_SELF_REG.
Figure 47 : test du service auto-enregistrement

Pour tester la fonctionnalité, on doit remplir le formulaire dédié pour ça, un fournisseur se
connecte au site de l’entreprise, et accède à un lien d’auto-enregistrement pour afficher le
formulaire.
La figure 48 montre le formulaire d’auto-enregistrement.
Figure 48 : formulaire d'auto-enregistrement
3.4. Paramétrage de présélection fournisseur :
L'acheteur accède à la présélection des fournisseurs dans SAP SRM.

Il examine les données de base et les formulaires dans le système d'enregistrement. L'acheteur
peut accepter ou refuser le fournisseur ; comme illustré dans la figure 49.
Figure 49 : Sélection des fournisseurs

Les fournisseurs acceptés sont affichés dans le répertoire des fournisseurs.
3.5. Paramétrage d’évaluation fournisseur :
L’évaluation des fournisseurs constitue une étape très importante après une période d’échanges
déterminée.
Nous avons paramétré cette fonctionnalité, en accédant, au guide de la référence, on choisit

dans le menu déroulant la catégorie d’évaluation, comme illustré dans la figure suivante :
Figure 50 : Choix de catégorie d'évaluation

Une fois activé, on peut tester le service qui assure cette fonctionnalité.

L’évaluation des fournisseurs se base sur l’envoi d’un formulaire d’évaluation, qui permet de
collecter les informations nécessaires sur les partenaires. Un exemple de formulaire est présenté
dans la figure 51.
Figure 51 : exemple de formulaire d'évaluation
3.6. Paramétrage de gestion des contrats :
Comme nous l’avons déjà mentionné dans le processus achat qu’on a modélisé (voir annexe
12), la gestion du contrat entre l'entreprise et le fournisseur sélectionné, en introduisant
éventuellement des clauses spécifiques concernant la logistique, les modalités de paiement, etc.,
est l’un des besoins cruciaux que notre client a exprimé.
Nous avons participé au paramétrage des contrats, en procédant de la même façon, au guide de
la référence avec la transaction, SPRO, nous avons défini les types des contrats et leurs tranches
de numéros comme illustré dans la figure 52.
Figure 52 : Définition de type des contrats et tranches de numéros

Conclusion :
Dans ce chapitre, nous avons essayé de donner une image sur le travail réalisé dans sa
globalité. Dans la partie 1, nous avons présenté les processus métier que nous avons déroulé
dans le système SAP Ariba, où on a démontré le flux d’un projet de sourcing, de gestion des
contrats, de processus P20 et de reporting. Et après avoir expliqué le passage d’Ariba à SRM,
nous avons présenté le travail réalisé dans le cadre de la phase conception et réalisation de la
méthodologie ASAP, à savoir, la définition des règles de gestion, identification des processus
à paramétrer, pour la phase de conception, en revanche nous avons pu paramétrés le live
auction, le bon de réception, l’auto-enregistrement, présélection, l’évaluation des fournisseurs
et la gestion des contrats dans la phase de réalisation.

Bilan et perspectives
Bilan et perspectives du projet :
1. Bilan du travail réalisé :
Deux types d’analyse sont effectués : la première analyse est liée à la gestion du projet
où nous présentons une comparaison du planning prévisionnel avec le planning réel. Quant à la
deuxième analyse, elle est consacrée au travail lui-même sa valeur ajoutée au niveau de
l’entreprise et au niveau de notre évolution personnelle et professionnelle.
1.1. Comparaison du planning réel et prévisionnel :
Le planning prévisionnel préalablement établi a subi plusieurs modifications. Cela est

dû aux contraintes suivantes :
 La non-disponibilité de l’équipe technique pour résoudre des problèmes et blocages
techniques.
 Quelques tâches attribuées sont nouvelles pour les consultants de la société ce qui a
exigé une montée en compétence.
 L’affectation d’autres tâches urgentes telles que la préparation des démos.
 Le temps alloué à la formation non-suffisant.
 Les solutions traitées lors de la durée de stage sont parmi les nouveautés de SAP, par
conséquent, nous n’avons pas trouvé beaucoup de ressources, notamment dans la partie
Ariba.
 La transition de la solution SAP Ariba à SAP SRM nous a freinés par rapport à la
planification prévisionnelle, ceci est principalement dû au temps consacré à la formation
et l’assimilation des concepts de SAP SRM.
Figure 53 : Diagramme de Gantt réel

Suite aux exigences imposées par ces contraintes, nous avons dû modifier et ajuster le planning
prévisionnel d’une manière à respecter les délais.
Le planning réel que nous avons suivi est dans la figure, et il est en détail en annexe 6.
1.2. Bilan des réunions effectuées :
Tout au long de la durée de notre projet, nous avons assisté à plusieurs réunions. Les réunions
ont généralement deux dimensions :
- Technique : Au moment où nous avions besoin de support de l’équipe technique.

- Encadrement, et validation des tâches : les réunions étaient organisées avec notre
encadrante professionnelle afin de valider, et faire le suivi des tâches.
- Stand Up meetings : des réunions très brèves dans le cadre de daily scrum.
Le tableau suivant présente le bilan final des réunions effectuées.
Nombre de réunions Durée totale (minutes)

Equipe technique 5 150
Encadrante professionnelle 16 640
Daily SCRUM 40 400
Tableau 10: Bilan des réunions
Au final, la durée totale des réunions effectuées est : 1190 minutes.
1.3. Supports réalisés :
Pour chaque objectif que nous avons réalisé durant le projet, nous avons rédigés des documents
fonctionnels qui sont nécessaires à la documentation. Les documents fonctionnels sont
généralement des fiches de conceptions, document de paramétrages, script de tests, support de
formation etc.
Les documents fonctionnels que nous avons mis en œuvre s’insère dans les deux phases du
projet réalisation et conception.
Dans la page suivante, les tableaux 11 et 12 récapitulent les supports réalisés.

Partie SAP Ariba :
Le tableau dans la page suivante est un résumé de tous les supports réalisés.
Travail Support réalisé

Gestion des appels d’offre Cartographie du processus de création des
appels d’offre.
Document de configuration des templates.
Gestion de la qualification fournisseur Documentation de processus de
qualification
Gestion des contrats Documentation de création et gestion des
contrats
Déroulement du flux P2O Documentation fonctionnel de processus
P2O
Tableau 11 : Bilan des supports sur Ariba
Partie SAP SRM :
Le tableau suivant représente les documents réalisés dans la partie SAP SRM :
Travail Support réalisé

Rédaction des fiches de conception Fiche article.
Fiche fournisseur.
Fiche réception de marchandises.
Paramétrage d’auto-enregistrement Document de paramétrage et fonctionnel.
fournisseur
Paramétrage de qualification fournisseur Document de paramétrage.
Paramétrage de SAP Live Auction Document fonctionnel et paramétrage
Paramétrage des contrats Document fonctionnel et paramétrage
Tableau 12 : Bilan des supports sur SRM
En résumé, 5 documents de paramétrage, 3 fiches de conception, constituent une partie des
livrables du projet destinés au client. Au sein de Value Pass, ces documents sont archivés et
présentent des supports de référence pour le transfert de connaissances, la formation des
nouveaux consultants et un modèle standard des livrables.
NB : Notre formation en SAP MM s’appuyait sur des documents livrés pour un projet chez
DIANA Holding, et un projet au profit du groupe Al Omrane pour la formation SAP SRM.

2. Bilan de compétences :
Le travail d’un consultant fonctionnel nécessite des compétences non seulement, de savoir-
faire mais aussi de savoir-être.
2.1. Compétences utilisées :
L’ensemble des compétences que nous avons utilisées durant toute la durée de notre travail au
sein de Value Pass Consulting.
 Gestion de projet :
 MS Project
 Charte du projet
 Méthodologie ASAP
 AMDEC
 Systèmes d’information et logistique :
 SAP SRM
 SAP Ariba
 MM SAP
 Modélisation des processus :
 BPMN
 Standard SAP pour la modélisation
2.2. Compétences développées :
La participation dans un projet de telle ampleur, nous a permis une montée en compétences
sur le niveau humain et métier. Les compétences développées durant notre projet :
 Plan humain :
 Adaptation
 Communication
 Ouverture d’esprit
 Ecoute
 Plan métier :
 Gestion des approvisionnements
 Gestion des contrats
 Gestion des appels d’offre et enchères

 Gestion de flux d’achat sur MM SAP

 Gestion de flux SAP Ariba
3. Perspectives :
3.1. Perspectives du projet : le ‘Should Be’
Notre projet d’implémentation de la solution de la gestion des achats pour AWB est en
cours de phase de réalisation et paramétrage. La suite de notre projet continue toujours suivant
la méthodologie ASAP, ce qui dit que dans la phase prochaine, nous entamerons les tests
unitaires et d’intégration sur le système SAP SRM, ainsi que la préparation des tests des
différents processus pour les ateliers de recette. Le projet s’enchainera par des formations des
utilisateurs et s’achèvera par la suite par une préparation finale, et la prise de décision de GO
ou NOGO.
En ce qui concerne le portail SRM, l’équipe Value Pass Consulting investit pour la formation
d’un consultant PI (Process Integration) qui va assurer le fonctionnement de l’interconnexion
entre SAP SRM et le portail d’entreprise.
Finalement, ce projet présente un modèle unique dans son genre pour Value Pass Consulting,
c’est une première expérience pour l’équipe MM à un projet dans le secteur bancaire. Ceci dit,
ce projet inédit représentera par la suite une référence des deux aspects de base du retour
d’expérience, le premier permet d’en tirer les meilleurs pratiques, et éviter les blocages en
second lieu.
3.2. Perspectives professionnelles :
Au niveau professionnel, cette expérience avait un immense impact, elle nous a permis
de développer nos compétences professionnelles et relationnelles, d'évoluer en tant que
consultants fonctionnels SAP, métier tant désiré, et de bien se préparer pour confronter le
monde professionnel.
Nous avons eu la chance d’acquérir un savoir-faire et un savoir-être pertinents, grâce

aux formations enrichissantes, l'encadrement de qualité et l'interaction avec les différents
consultants : fonctionnels, technico-fonctionnels et techniques.
Nous avons eu l'honneur de travailler avec l'équipe sur des tâches décisives et critiques
ce qui nous a permis d’augmenter notre confiance en soi et notre aisance vis-à-vis des situations

critiques. Finalement, grâce à ce stage de fin d'études, nous sommes capables de tracer une ligne
droite vers notre objectif professionnel : CONSULTANT FONCTIONNEL SAP.
3.3. Conduite du changement :
Indépendamment de la typologie du projet, le facteur humain représente un vrai défi dans sa

réussite, particulièrement dans les projets d’intégration des SI, c’est pour cela que la mise en
place d’une démarche de conduite du changement s’avère très importante pour notre projet ;
dans cette optique, Value Pass Consulting propose des différents chantiers à mener, à savoir :
 Processus de décision : Permettre au management de décider concernant les processus ;

 Communication : Assurer l’implication à chaque phase par la communication ;
 Stratégie des alliés : S’assurer du soutien actif des acteurs-clés du projet ;
 Animation de l’équipe projet : Créer une équipe projet solidaire et efficace ;
 Ecoute et gestion des risques : Remonter en permanence les problèmes et procès ;
 Formation : Assurer un bon niveau de connaissance des processus ;
 Support au démarrage : Permettre aux utilisateurs une aide efficace au démarrage ;
 Définition des indicateurs de performance : Défini les indicateurs de suivi de projet.

Conclusion générale :
Dans le cadre de l’amélioration de son processus d’approvisionnement et d’achat, et afin

d’adopter une nouvelle approche basée sur le e-approvisionnement, le groupe Attijari Wafa
Bank a opté pour l’implémentation de la solution de gestion d’achats et de relation fournisseurs
SAP SRM. Cette implémentation constitue un grand défi aussi bien pour le client que
l’intégrateur.
A l’aide de cette nouvelle pratique, le client aura une meilleure visibilité sur toutes ses
filiales grâce à la standardisation des processus et l’assurance de la traçabilité des activités
effectuées. Il sera aussi capable d’optimiser le cycle d’approvisionnement en termes de coûts
et délais d’exécution. En outre, le système permettra au client d’évaluer la performance de son
processus et ses fournisseurs.
Notre contribution dans le projet a été spécialement dans le déroulement du flux sur la
nouvelle solution SAP Ariba, et dans les deux phases de conception et réalisation de la
méthodologie ASAP adoptée pour la gestion de ce projet.
Notre participation avait un impact important sur l’évolution de notre compétence dans
le domaine d’intégration des progiciels de gestion intégrés. La conception des différents
processus et les paramétrages réalisés sur le système nous ont aidé, non seulement à s’habituer
à la manipulation du système et les différents environnements du travail, mais aussi de se mettre
dans la peau d’un consultant fonctionnel et gérer les différentes situations critiques dans le
projet tel que les anomalies, les situations de blocage et la prise d’initiative.
Cette expérience nous a permis aussi de découvrir de nouveaux concepts fonctionnels

présents dans les solutions de gestion d’achat SAP tels que la gestion des appels d’offres,
enchères, contrats, processus achat et approvisionnement, processus de présélection et
d’évaluation fournisseur, dépenses achat etc. Ainsi que des concepts métier en relation avec
l’approvisionnement dans le secteur banquier.
Notre interaction avec les différents consultants techniques, fonctionnels et technico-

fonctionnels nous a aidé à développer nos compétences au niveau de management du projet, le
travail d’équipe et gestion du temps ainsi qu’acquérir les bonnes pratiques du métier.
Finalement, nous étions fiers et honorés de notre participation à ce projet, surtout après
avoir palpé l’impact organisationnel d’un tel projet pour une banque. Les solutions seront

proposées aux anciens clients, nouveaux et potentiels. Ainsi, nous avons eu l'opportunité
d’assister à la réponse à un appel d'offre pour un client prospect CFG Bank. Lors de cette
participation, nous avons évoqué les différentes fonctionnalités liées à SAP Ariba et SAP SRM.

BIBLIOGRAPHIE
- Documents de formation internes (Value Pass).

- Padma Prasad Munirathinam et Ramakrishna Potluri, The Consultant’s Guide to
SAP SRM, SAP Press, Galileo Press, 2008
- Jean- Luc DEIXONNE, Piloter un projet ERP, DUNOD, Paris, 2011, 285p.
- Rémy LEMOIGNE, Supply chain management, DUNOD, Paris, 2013, 293p.
WEBOGRAPHIE
- Ariba exchange user community ;
Consultations du 08 Mars 2017 au 12 Avril 2017
- www.help.sap.com
Consultations : du 28 Février 2017 au 20 Aout 2017.
- www.scn.sap.com
Consultations : du 10 Avril 2017 au 20Aout 2016.
- www.lesguidessap.com
Consultations : du 15 au 28 Février 2017

ANNEXES

Liste des annexes :
Annexe 1 : Enjeux et fonctionnalités AWB ............................................................................. 77
Annexe 2 : Rôle des intervenants ............................................................................................. 80
Annexe 3 : Charte du projet ..................................................................................................... 81
Annexe 4 : Méthodologie ASAP .............................................................................................. 83
Annexe 5 : Les responsabilités des parties prenantes au cours la méthodologie ASAP .......... 85
Annexe 6 : Diagrammes de Gantt prévisionnel et réel en détail .............................................. 86
Annexe 7 : Tableau AMDEC ................................................................................................... 88
Annexe 8 : Tableau des Sprint exécutés................................................................................... 90
Annexe 9 : Scénarios d’intégration de SRM ............................................................................ 91
Annexe 10 : Annexe Ariba ....................................................................................................... 92
Annexe 11 : Modélisation BPMN du processus P2O .............................................................. 93
Annexe 12 : Modélisation BPMN de schéma cible AWB ....................................................... 94
Annexe 13 : Exemples de fiches de conception ....................................................................... 95
Annexe 14 : Live auction cockpit............................................................................................. 97
Annexe 15 : Paramétrage des messages – Bon de réception .................................................... 99
Annexe 16 : Modélisation du processus de gestion des contrats ........................................... 101
Annexe 17 : Portail SRM ....................................................................................................... 102

Annexe 1 : Enjeux et fonctionnalités AWB
ENJEUX AWB :
 Enjeux stratégiques et métiers :

 Remplir efficacement la mission de l'Attijari Wafa Bank
 Disposer un système des achats conforme aux dispositions légales des marchés publics
et au règlement de l'Attijari Wafa Bank
 Construire avec l'écosystème des Achats une relation bâtit sur la transparence et la
confiance
 Disposer d'un outil de pilotage des achats efficients
 Enjeux humains et organisationnels :
 Aligner les Processus, les Systèmes et l’Organisation
 Fournir aux utilisateurs des outils performants qui leur faciliteront leur travail au
quotidien
 Réussir le changement avec l’adhésion des ressources humaines
 Enjeux processus :
 Fournir en continu des produits et des services innovants
 Standardisation des processus d'achats
 Utilisation des meilleures pratiques sectorielles
 Enjeux technologiques :
 Améliorer la fiabilité des informations
 Améliorer la productivité des utilisateurs
 Diminuer les délais de traitement de l’information
 Disposer d’outils robustes et durables
 Utilisation des dernières innovations technologiques
FONCTIONNALITES DEMANDEES :
Récupérer du système existant
Gestion des dossiers administratifs
Gestion et réception des offres de service spontanées
Envoi du RFP

Réception des Offres
Dépouillement et comparatif technique administratif et financier
Négociations financières (1 ou plusieurs Rounds)
Etablissement des PV de décisions
Gérer les sorts des dossiers achats selon le budget (clôturer le dossier)
Disposer d’une aide à la décision réelle lors de la sélection d'un fournisseur :

outil d'analyse multi critères
Homologation et présélection des fournisseurs
Avoir une vision globale de l’activité Achats et répartition optimisée entre les
acheteurs
Standardisation des canevas des remises des offres avec tous les
soumissionnaires
Donner la possibilité aux fournisseurs de déposer leurs offres sur le site durant
un période définie par le système achat
Donner la possibilité aux utilisateurs de prolonger les périodes de réponses

aux AO
Permettre aux fournisseurs de poser leurs questions et permettre de diffuser

les réponses à l’ensemble des soumissionnaires
Disposer d’une plateforme pour les enchères.
Gérer les différentes étapes du processus achat de manière collaborative
Avoir la possibilité de mettre en place des modèles de dossier achat et de les

utiliser (Envoi RFP) et bibliothèque Achats
Suivre l'activité des fournisseurs consultés : permettre d’avoir une traçabilité

sur tous les échanges effectués avec les prestataires (
Gérer le mailing interne et externe

Gérer une base documentaire relative au dossier achat en cours
Permettre de faire un suivi des rounds de négociation effectué avec les

prestataires
Permettre de Calculer pour chaque dossier ou AO traité les économies et

performances réalisées (….)
Donner la possibilité à l’utilisateur de saisir (ou charger) ses propres grilles

de notation
Inviter les parties prenantes du dossier achat à noter les offres fournisseurs
Disposer d'analyse comparative des offres sur des critères qualitatifs et

quantitatifs qui permettent de sélectionner l'offre la plus intéressante.
Disposer de fonctionnalités d'analyse et de décomposition des coûts
Permettre la gestion de projet Achat complexe ou portant des gros volumes

d'articles à chiffrer
Disposer d'outils de Reporting permettant une vision stratégique de l'activité
Permettre l’archivage électronique des dossiers et AO pour consultation à

posteriori.

Annexe 2 : Rôle des intervenants
Directeur de Projet : Le Directeur de Projet Attijariwafa bank supervise l’avancement du projet
et est responsable de l’affectation de ressources adéquates et du processus de résolution des
questions soulevées par l’équipe projet.
Directeur de Projet VP : Le Directeur de Projet Value Pass assure la relation avec la Direction
de Projet client, coordonne l’avancement des travaux de l’équipe ValuePass ainsi que la qualité
des livrables. Son rôle est également un rôle de directeur qualité. Le directeur de projet VP est
un associé Value Pass.
Chef de Projet fonctionnel Attijariwafa bank : Le Chef de Projet fonctionnel est un des acteurs
principal du projet. Il s’assure que les besoins fondamentaux sont adressés. Il suit l’avancement
du projet et valide les principaux livrables. Il est en charge de la mobilisation des ressources
internes et de la conduite du changement tout au long du projet
Chef de Projet VP : Le Chef de Projet ValuePass est un chef de projet Senior. Il est responsable
de la gestion de l’équipe projet VP et de la relation avec le Chef de Projet client. Il est aussi
responsable de la livraison des livrables conformément au planning.
Garants Métiers Attijariwafa Bank : Les Garants Métiers sont les Responsables de chaque
domaine fonctionnel désignés par Attijari Wafa Bank pour valider les processus mis en place
avec la nouvelle solution. Leur disponibilité pour le projet est au minimum de 2 jours par
semaine.
Chef de Projet Domaine VP : Les Chefs de Projet ‘Domaine’ ValuePass sont les responsables
de la solution et de leurs domaines respectifs. Ils sont responsables de l’organisation du travail
et de la planification des travaux à l’intérieur d’un domaine fonctionnel. Ils reportent au chef
de projet Value Pass.
Utilisateurs clé : Les Utilisateurs Clé participent à l’ensemble des travaux concernant leur
domaine fonctionnel : Conception – Recette – Formation. Ils sont enfin responsables de la
solution SAP qui sera définie. Leur disponibilité pour le projet devra être d’environ 2 à 3 jours
par semaine (varie en fonction des phases du projet)
Consultants Fonctionnels ValuePass : Les Consultants fonctionnels de la conception et de la
configuration détaillée des processus opérationnels dont ils ont la charge dans le système SAP.
Ils préparent la mise en production avec l’assistance des utilisateurs clé.
Equipe Technique Value Pass : L’équipe technique, composée d’un architecte et de
développeurs Value Pass, assure la réalisation des programmes spécifiques : adaptation d’états
et formulaires – réalisation interfaces.
Développeurs Attijariwafa bank : Les développeurs Attijariwafa bank seront dans la mesure
du possible intégrés à l’équipe technique Value Pass, de manière à garantir le transfert de
compétences. Ils seront encadrés par le team leader technique/architecte Value Pass.
Equipe Administration Informatique : Cette équipe est composée d’un consultant Value Pass
(BC) et d’Administrateurs Système client pour assurer l’installation et l’exploitation des
solutions mises en œuvre.

Annexe 3 : Charte du projet
Intitulé du projet : Implémentation Version Préliminaire - Version 0
d’une solution SAP
pour la gestion des
achats au profil
d’AWB
Date: 22/4/2017
Client du projet: AWB
Chef de projet : Mme. GUEMOURIA
DÉFINITION DU PROJET
1. OBJECTIF ET LIEN STRATÉGIQUE (Objectif global du projet)

Garder un partenariat durable et stable avec AWB via la réalisation du ce projet.
2. BUTS DU PROJET (Objectifs spécifiques du projet)
Réalisation des paramétrages
Implémentation des solutions
3. BÉNÉFICES RECHERCHÉS
Pour l’entreprise :
Proposer des nouvelles solutions pour les clients
Augmenter le bénéfice.
Pour son personnel :
Améliorer les compétences.
Faciliter les opérations.
Pour ses clients :
Améliorer le processus d'approvisionnement/achat et la gestion de relation fournisseur.
4. STRATÉGIES DE RÉALISATION DU PROJET
Préparation
 Conception
Réalisation
Documentation/Tests
Validation
5. PRINCIPAUX LIVRABLES DU PROJET ET DATES PRÉVUES

Les manuels de paramétrage (mois juin) - les documents de formations (mois juillet) - les vidéos
de démonstration (mois Août)
AUTRES PARAMÈTRES
7. BUDGET DU PROJET
Confidentiel
8. CONTRAINTES CONNUES
Contrainte de délai de projet et les différentes dates jalons
Les compétences et les prérequis sur SAP Ariba et SAP SRM
Capacité journalière du travail 8 heures / Homme
 Appliquer les techniques et méthodes de gestion de projet
 Assimiler les processus SAP SRM/MM et SAP Ariba
 Accéder aux données et informations nécessaires
 Indisponibilité des ressources de support et technique
9. IMPACTS SUR LES OPÉRATIONS DE LA SOCIÉTÉ

Changement de la structure informationnelle et organisationnelle de l’entreprise précisément la
partie achat/approvisionnement et relations avec les fournisseurs
10. RESPONSABILITÉS DU COMITÉ DE PILOTAGE
Planification
Réalisation
Evaluation
Validation
11. CRITÈRES DE TERMINAISON DU PROJET
Suivi.
évaluation
Validation

Annexe 4 : Méthodologie ASAP
La méthodologie ASAP se base sur les 5 phases suivantes :
1. Phase I : Préparation du Projet
Cette première étape a pour but d’établir les premiers accords du projet ainsi que la constitution
de l’équipe du projet, parmi les activités principales de cette étape :
- Rédaction du Plan d’Assurance qualité (charte projet).
- Définition du planning détaillé du projet.
- Définir les structures du projet.
- Réunion de lancement officielle.
- Initiation de l’équipe du projet.
- Installation système de DEV avec les scénarios préconfigurés.
2. Phase II : Conception, Analyse écarts / prototype
Pendant cette phase l’équipe Value Pass affectée à ce projet a comme tâches principales :
- Rédaction des fiches de conception (générale et détaillée).
- Identification des écarts.
- Configuration initiale du système : prototype.
- Définition des règles et procédure de développement SAP.
- Premières spécifications et développements.
- Définition de la stratégie de reprise des données.
En ce qui concerne l’équipe du client, elle a comme responsabilités les tâches suivantes :
- Participer aux ateliers SAP d’analyse d’écart.
- Valider les processus futurs.
- Identifier les impacts organisationnels.
- Arbitrer les exceptions (comité de pilotage).
3. Phase III : Réalisation
Les objectifs principaux de la réalisation sont de configurer le système, tester et de

préparer la formation. D’autre part, la collaboration de l’équipe Value Pass et l’équipe AWB
est à son apogée pendant cette phase, car il s’agira pour l’équipe Value Pass de faire les tâches
suivantes :

- Configurer les processus en accord avec les besoins.
- Réaliser les tests unitaires, d’intégration et de performance.
- Rédiger des cahiers de recette (scripts détaillés).
- Faire le suivi des recettes (processus et globale) et corrections.
- Implémenter le système d’autorisations (implication forte AWB).
- Préparer des formations (plan et supports).
L’équipe AWB de son côté, se chargera des tâches suivantes :
- Réaliser les tests de recette
- Enregistrer les incidents
- Re-tester les processus non validés
- Définir des tâches et fonctions
- Définir le modèle de support pour le post go-live.
4. Phase IV : Préparation finale
A l'instar des autres phases, celle-ci nécessite la coopération des deux équipes pour
pouvoir conclure les tests, former les utilisateurs finaux et migrer les données de l’ancien
système vers le nouveau.
5. Phase V : Démarrage et support
C’est la phase ultime de mise en production de l'ERP ou SRM, où l’équipe Value Pass
est menée à se mobiliser pour assister les utilisateurs pendant les premières transactions,
finaliser la documentation support et pour résoudre les anomalies susceptibles d’apparaitre au
cours du go-live final.

Annexe 5 : Les responsabilités des parties prenantes au cours la méthodologie
ASAP
Responsabilités
Activités
Value Pass AWB
- Plan du projet - Logistique projet - Définir le plan du projet
- Initiation des équipes - Fourniture - Définir les modèles des
Préparation/
- Planification détaillée infrastructure technique documents
Lancement
- Installation SAP et activation
des préconfigurés
- Identifier les processus à - Participer aux ateliers - Rédaction des fiches de
paramétrer SAP d’analyse d’écart conception (générale et
- Animer les ateliers de - Valider les processus détaillée)
conception futurs - Identification des écarts
Conception
- Définir les règles de - Fournir les données - Rédaction des spéc. Techn.
gestion nécessaires - Définition des règles et
- Planification phases procédures de développement
suivantes SAP
- Configurer le système et - Fournir les cahiers de - Configurer les processus en
tests usines (unitaires et recette accord avec la conception
intégrés) - Fournir les données à - Réaliser les tests unitaires et
- Réalisation de reprendre d’intégration
développements - Mobiliser les ressources - Rédaction des cahiers de
- Transfert de compétences à la recette recette (scripts détaillés)
Réalisation
- Assistance à la recette - Réaliser les tests de la - Implémentation du système
et recette
- Correction d’anomalies recette d’autorisations
- Préparation des formations
(plan et supports)
- Préparation du plan de bascule
- Paramétrage des outils de
chargement de données
- Tests et finalisation des - Validation des données - Exécution du plan de bascule
outils de chargement reprises - Organiser l’équipe pour le
- Suivi de l’exécution du - Mobilisation des support de production
plan de bascule utilisateurs - Définition du plan de bascule
Préparation - Exécution de reprise en - Logistique de formation détaillé
finale production - Migration de données
- Finalisation des supports définitives
de formation - Finalisation de
- Formation des utilisateurs l’environnement de production
finaux
- Support niveau 2 et - Exécuter les tâches du - Support aux utilisateurs clés
Démarrage/ résolution d’anomalies go-live final - Support en central
Support - Assistance aux utilisateurs - Assurer les conditions - Formations complémentaires
d’une amélioration
Annexe 6 : Diagrammes de Gantt prévisionnel et réel en détail
Diagramme de Gantt prévisionnel
86 solution SAP pour la gestion des achats

PFE ǁ Implémentation d’une
Diagramme de Gantt réel 87 solution SAP pour la gestion des achats
Annexe 7 : Tableau AMDEC
Fonction Moyen Existant Actions à
Libellé Cause Anomalie Effet O G D C entreprendre
Absence de plan Stratégie de Travail non Etablir une bonne
prévisionnel planification structuré organisation du
incorrecte 4 3 4 48 projet en utilisant les
différents outils de
planification
Planification Mauvaise Objectifs trop Résultat Demander l’avis de
connaissance ambitieux partiel du 7 3 1 21 l’encadrant et rester
des contraintes projet réaliste
et difficultés
Difficulté Surcharge du Recul du Allouer une durée
d’estimer la travail travail suffisante/nécessaire
durée de chaque 7 6 4 168 à chaque tâche
tâche
Plan de Manque de Faible Veiller à enlever les
communication communication efficacité barrières de
initial non entre les 7 3 1 21 communication
respecté différents quotidiennement
acteurs du projet
Vision Conflit d’intérêt Manque de Partager la même
personnelle du synergie vision du projet
projet au lieu entre les 4 1 7 28
Communication d’une vision acteurs
collective
Difficulté de Manque de Analyse Bonne relation avec
collecte des données non le personnel de tout
informations et exhaustive 7 3 4 84 le personnel
confidentialité du
des données problème

Indisponibilité Absence Retard Anticipation des
de d’encadrement d’exécution mises au point et
l’encadrante des tâches fixation des objectifs
pour vérifier et ou de des prochaines
valider le travail validation 7 6 4 168 étapes du projet
des étapes
du projet.
Implication Manque de Ambition Travail Penser au moment
Motivation personnelle incomplet 4 10 7 280 glorieux si le projet
ou bâclé est réussi
Raisons Absentéisme Surcharge 4 9 4 144 Se forcer à rattraper
multiples de travail le temps d’absence
Méthodologie Analyses Résultats Prendre son temps
d’analyse erronées et non fiables. pour analyser les
inefficace chiffrage non 1 6 7 42 données et s’inspirer
crédible. d’autres études
Savoir-faire Solution non Refus des Perte de Partage des idées
pertinente ou actions et temps et avec les acteurs du
difficile à mettre solutions aucune projet et
en place proposées valeur 1 10 7 70 l’implication des
ajoutée pour intervenants lors de
l’entreprise. la prise de décision
Outils et Difficulté Résultats Documentation sur

méthodes non d’appliquer les incohérents 1 10 1 10 les différents outils
assimilés méthodes et du projet et méthodes
outils proposés
Tâche non Besoin Retard dans Remonte de
accomplie due à d’intervention le planning l’information au
la nécessité de l’équipe du travail manager et team
7 6 1 42
d’une technique lead de l’équipe
intervention technique
technique

Annexe 8 : Tableau des Sprint exécutés
Sprint Période Objectifs

1 du 15/03 au 28/03 Déroulement du processus de planification sur SAP Ariba
2 du 30/03 au 12/04 Déroulement du flux P2O, et préparation des scénarios de

démonstration
3 du 20/04 au 03/05 Etude de l’existant et rédaction des spécifications
fonctionnelles
4 Du 05/05 au 25/05 Conception de la solution SRM
5 Du 26/05 au 07/06 Rédaction des fiches de conceptions
6 Du 09/06 au 22/06 Paramétrage de la solution SRM

Annexe 9 : Scénarios d’intégration de SRM
Scénario Description
tous les documents achats sont créés sur SAP

SRM. Seul les factures, la comptabilité et les
Scénario local (standalone)
payements qui sont gérés sur le système
backend
le panier est créé sur SAP SRM et les
documents achats qui en découlent son crées
Scénario classique sur le système backend. La réception de

marchandises et les factures peuvent être gérer
soit sur SAP SRM ou bien sur le système
backend
pratiquement tous le processus achat est géré
sur SAP SRM dans ce scénario. Les
documents achat sont créés sur SAP SRM et
Scénario classique étendu sont répliqués sur le système backend.
identiquement au scénario classique, La
réception des marchandises et les factures sont
gérés soit sur SAP SRM ou bien sur le
système backend.
SAP SRM n’a pas de scénario intitulé découplé,
ce terme est utilisé par abus de langage. Ce
scénario est déployé lorsque le modèle
applicatif de l’entreprise requiert l’utilisation
des trois scénarios précédents en parallèles. Par
Scénario découplé
exemple, on peut gérer les types d’articles sur
la base de scénarios différents (les achats
d’investissement peuvent être traités en
scénario local, les achats stockés en scénario
classique, et les prestations de services en
scénario classique étendu).

Annexe 10 : Annexe Ariba
1. La création de n’importe quel document, projet, événement se fait cliquant sur créer
visible à droite de la plateforme.
2. Une page s’ouvre contenant les différents champs à renseigner correspondant à chaque
type d’éléments qu’on désire créer.

Annexe 11 : Modélisation BPMN du processus P2O

Annexe 12 : Modélisation BPMN de schéma cible AWB

Annexe 13 : Exemples de fiches de conception
Exemple de fiche de conception – fiche article
Exemple de fiche de conception – fiche fournisseur

Exemple de fiche de conception – fiche réception

Annexe 14 : Live auction cockpit
Bug de live auction :
Cette erreur a été rencontré lors de paramétrage des enchères, et qui a été résolue en utilisant
une note SAP qui est dédiée pour la résolution de cet erreur.
Note SAP 2075978 (JAVA Auction)

Un test de live auction a été réalisé ci-après.
On peut suivre en temps réel les différentes offres des soumissionnaires, suivant les règles de
dépôt préétablies.

Annexe 15 : Paramétrage des messages – Bon de réception
Le formulaire ZMM_BON_RECEPTION utilisé pour le paramétrage des bons de réception.

BON DE RECEPTION N° 5000000040
Division : Attijari Wafa Bank central Bon de commande : 4500000018
Magasin : Fournisseur : MAGIC PRINT
Bon de livraison : Reçu Par : YBarzouhi
Date : 21.05.2017
Code Article Désignation Quantité Unité Lot Observation
A600050 CLE USB VIP + COFFRET 60 Pce
Attijari Wafa Bank- 2, bd Moulay Youssef, Q.

Lusitania CASABLANCA Téléphone/standard:
+ 212 5 22 20 36 11/+212 5 22 20 36 09
100
PFE ǁ Implémentation d’une solution SAP pour la gestion des achats
Annexe 16 : Modélisation du processus de gestion des contrats
101
PFE ǁ Implémentation d’une solution SAP pour la gestion des achats
Annexe 17 : Portail SRM
Le portail SRM représente une interface web, accessible par internet, qui intègre des
fonctionnalités liés à SAP SRM destinées à faciliter et harmoniser la relation avec les
fournisseurs stratégiques.
Après l’enregistrement du fournisseur par les acheteurs, celui-ci reçoit un identifiant et mot de
passe pour pouvoir accéder au portail à travers une adresse URL.
Du fait qu’il est installé sur le web le portail est protégé par un pare-feu pour éviter toute
tentative d’espionnage ou de piratage. Ainsi, le seul élément qui permettra l’interconnexion
entre SAP SRM et le portail est une couche appelé PI.
Le portail SRM comprend deux grandes fonctionnalités. La première permet aux fournisseurs
de répondre aux appels d’offres, et de participer aux enchères en temps réel.
La deuxième fonctionnalité apporte au fournisseur la possibilité d’approuver les commandes,
de recevoir des messages par rapport aux commandes et réceptions, ainsi que d’envoyer des
avis préalables d’expédition ou de contrôler leur programme de livraison.
Il existe deux scénarios d’intégration de SUS :
- Service Procurement : SUS est installé séparément et paramétré pour travailler avec
SRM. D’un point de vue technique, la connexion à SAP SRM représente un scénario
‘Standalone’ avec la comptabilité financière comme système backend.
Plan driven Procurement with supplier Integration : SUS est paramétré pour travailler avec MM,
d’un point de vue technique ceci représente un scénario classique avec un ou plusieurs système
back end.

Langue

Rapport PFE - El BARZOUHI - BEGDOURI

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Rapport PFE - El BARZOUHI - BEGDOURI

Titre original :

Transféré par

Droits d'auteur :

ECOLE NATIONALE DES UNIVERSITE

SCIENCES APPLIQUEES DE ABDELMALEK ESSAÂDI

PROJET DE FIN D’ETUDES

Présenté à l’Ecole Nationale des Sciences Appliquées de

Tanger pour obtenir le diplôme de

Ingénieur d’état en Génie industriel et logistique

Implémentation d’une solution SAP pour la gestion des

achats au profit de AWB

BEGDOURI ACHKARI Ibrahim

M.MOTAKI Noureddine : Professeur chercheur à l’ENSA de Tanger

Mme.OUADY Amal : Manager d’équipe Achat/Logistique à Value Pass Consulting.

Mme.GUEMOURIA Ghita : Consultante fonctionnelle Senior SAP MM/SRM.

Année Universitaire 2016 - 2017

BEGDOURI ACHKARI Ibrahim

Au Dieu Tout Puissant,

A mes très chers parents,

A mes sœurs Sofia, Meriem, Chaimae et à mon frère Mohammed,

A toutes les personnes qui me sont chères,

A mon binôme, Begdouri Achkari Ibrahim,

A mes frères Amine et Muhammad

A mes sœurs, Assia, Soukayna, Oumayma, et la petite Soumayah

A mes très chers amis,

A mon binôme EL Barzouhi Youssef

iv BEGDOURI ACHKARI Ibrahim

Nous souhaitons remercier en premier lieu notre encadrant, Monsieur MOTAKI

ABAP: Advanced Business Application Programming

AMDEC : Analyse des modes de défaillances de leurs effets et de leurs criticités.

AMOA : Assistant à maîtrise d’ouvrage

AO: Appel d’offre

ASAP: Accelerated SAP

ASN : Advance Ship Notice

AWB: Attijari Wafa Bank

BC: BASIS Components

BPMN: Business Process Modeling and Notation

BW: Business Warehouse

CRM: Customer Relationship Management

DFS : Distributed file system

ECC: ERP Central Component

HCM: Human Capital Management

MM: Material Management

MOA : Maître d’ouvrage

MOE : Maître d’œuvre

P2O: Procure to Order

P2P: Procure to Pay

PI: Process Integration

QQOQCP : Qui, Quoi, Où, Quand, Combien, Pourquoi.

SAP: System, Application and Products in data processing

SAP SUS: SAP Supplier Self-Service.

SCN: SAP Community Network.

SI: Système d’information

SIPOC: Supplier, Input, Process, Output, Customer.

SMI: Small and Medium Enterprise.

SRM: Supplier Relationship Management

SWOT: Strength, Weakness, Opportunity, Threats.

TCO: Total Cost of Ownership

VP : Value Pass Consulting

ASAP : c'est une méthodologie/approche pour l'implémentation de solutions SAP

Figure 1: Organigramme de Value Pass ..................................................................................... 6

Tableau 1: Questions QQOQCP .............................................................................................. 10

1 PFE ǁ Implémentation d’une solution SAP pour la gestion des achats

2 PFE ǁ Implémentation d’une solution SAP pour la gestion des achats

Cadre général du projet

Dans ce chapitre, nous avons situé notre projet de

3 PFE ǁ Implémentation d’une solution SAP pour la gestion des achats