Mettre en œuvre et piloter un projet ERP · Mettre en œuvre et piloter un projet ERP isbn :...

of 14/14
Hervé PETIT Mere en œuvre et piloter un projet ERP
  • date post

    21-May-2018
  • Category

    Documents

  • view

    216
  • download

    0

Embed Size (px)

Transcript of Mettre en œuvre et piloter un projet ERP · Mettre en œuvre et piloter un projet ERP isbn :...

  • Mett

    re e

    n

    uvre

    et p

    ilote

    r un

    proj

    et E

    RP

    isbn

    : 978

    -2-4

    09-0

    1152

    -8

    Mettre en uvre et piloter un projet ERP La mise en place dun ERP nest pas un projet comme les autres : si tous les projets de lentreprise impactent la fois certains process et certaines organisations, un projet ERP les impacte tous. Cest donc une profonde mutation de lentre-prise, un changement radical qui ponctue un avant et un aprs.Choisir un ERP est une dcision stratgique qui concerne le Systme dInforma-tion, mais galement tous les mtiers de lentreprise.Ce livre est destin aux directions gnrales, aux directions mtier et tous les acteurs du projet ; il a comme objectif de vous guider dans la mise en place et le suivi dun tel projet pour vous aider faire de ce projet une russite ! Au fur et mesure des chapitres, les diffrentes phases du projet sont prsentes : de la phase de conception la phase de support post-dmarrage, sans oublier les phases davant-projet et daprs projet qui sont essentielles sa russite.Sont prsents galement les rles des diffrents acteurs du projet, internes ou externes, et les rles des instances de dcision puis, les mthodes et outils accessibles par tous et ne ncessitant pas de technologie particulire.Le dernier chapitre met en avant le dessous des cartes en prsentant, sous la forme de dialogues entre acteurs potentiels du projet, des situations mettant en vidence certaines rsistances classiques au changement.Enfin, un lexique anglais/franais des termes couramment employs dans ce type de projet, notamment dans les projets internationaux, pourra tre dune grande utilit.Ecrit dans un langage volontairement accessible tous, cet ouvrage met en avant les facteurs cls du succs et livre les piges et cueils viter.

    Herv PETITDirecteur de projet ERP (Dynamics AX, SAP, PeopleSoft) pour de grands groupes internationaux depuis prs de 25 ans, Herv PETIT a particip limplmentation, au dploiement dans de nombreux pays et laccom-pagnement au changement de nom-breux projets. A travers cet ouvrage, il vous livre toute son exprience acquise durant toutes ces annes.

    Les chapitres du livre

    Pour plus dinformations :

    45

    Introduction Lavant-projet Les acteurs du projet La mise en place du projet Le dmarrage du nouveau SI Les mthodes et outils essentiels Le dessous des cartes

    Herv PETIT

    Mettre en uvre et piloter

    un projet ERP Tlchargementwww.editions-eni.fr.frsur www.editions-eni.fr : b Fishbones prsents

    dans le livre.

  • 1Table des matires

    Avant-propos

    Chapitre 1

    Introduction

    1. Un ERP, cest quoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

    2. Les flux qui traversent lentreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

    3. Consquences du choix dun ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

    4. Les facteurs cls de succs/chec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.1 Sponsorship de la direction gnrale . . . . . . . . . . . . . . . . . . . . . 124.2 Gestion du planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

    4.2.1 Dmarrer date fixe inchangeable . . . . . . . . . . . . . . . . . 144.2.2 Dmarrer quand on est prt . . . . . . . . . . . . . . . . . . . . 154.2.3 La troisime voie : dmarrer quand il faut ! . . . . . . . . . . 16

    4.3 Objectif clair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4 Management align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.5 Volont de converger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.6 Capacit prendre des dcisions rapidement . . . . . . . . . . . . . . 184.7 Ressources disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.8 Accompagner le changement. . . . . . . . . . . . . . . . . . . . . . . . . . . 19

    5. Les risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

    6. Tableau dvaluation dun projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

    7. La rsistance au changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227.1 Comment lutter contre la rsistance au changement ? . . . . . . 23

    lcroiseTampon

  • 2 Mettre en uvre un projet ERP

    Chapitre 2

    Lavant-projet

    1. La stratgie Systme dInformation . . . . . . . . . . . . . . . . . . . . . . . . . . 251.1 Le constat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.2 Le SWOT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

    1.2.1 Exemple dun SWOT SI . . . . . . . . . . . . . . . . . . . . . . . . . . 291.3 Le plan stratgique du Systme dInformation . . . . . . . . . . . . 291.4 Le trajet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.5 Ladaptation de la stratgie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

    2. Le pr-projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.1 Un cahier des charges ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.2 Les critres de slection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

    2.2.1 La prennit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2.2 Scalabilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2.3 Dployabilit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

    2.3 La contractualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.1 Escrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

    2.4 Le choix de lditeur et de lintgrateur. . . . . . . . . . . . . . . . . . . 352.4.1 Les rfrences de lintgrateur ou de lditeur. . . . . . . . . 352.4.2 Les erreurs ne pas faire. . . . . . . . . . . . . . . . . . . . . . . . . . 36

    2.5 Le choix du directeur de projet . . . . . . . . . . . . . . . . . . . . . . . . . 362.5.1 La DSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.5.2 La DAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.5.3 Le comit de direction . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.5.4 Un directeur de projet externe. . . . . . . . . . . . . . . . . . . . . 37

    3. Lobjectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1 Projets sans fin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2 Le temps dans lobjectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3 Objectif mesurable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4 Le vritable objectif du projet dpend du client interne . . . . . 41

    4. Le planning du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

  • 3Table des matires

    5. Le cot du projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.1 Les cots du RUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2 Cot complet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

    6. Les gains du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

    7. La stratgie de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

    8. Le Kick Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

    Chapitre 3

    Les acteurs du projet

    1. Les acteurs du projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631.1 Les Key Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641.2 Les directions mtier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651.3 La DSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661.4 La DRH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671.5 Les futurs utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681.6 La socit de conseil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681.7 Lditeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691.8 Lintgrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

    2. Les instances de dcision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.1 Le comit projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.2 Le comit de pilotage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.3 Le comit stratgique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

    Chapitre 4

    La mise en place du projet

    1. La conception : le "design" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731.1 BPR : Business Process Reengineering . . . . . . . . . . . . . . . . . . . . 731.2 Core Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751.3 Les scnarios de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761.4 Latteinte des objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . 81

  • 4 Mettre en uvre un projet ERP

    1.5 Les demandes de dveloppements spcifiques . . . . . . . . . . . . . 951.6 Lorganisation des supports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961.7 Lorganisation de cration, modification,

    suppression dun utilisateur. . . . . . . . . . . . . . . . . . . . . . . . . . . . 961.8 Lorganisation dattribution de profil(s) un utilisateur,

    modification, suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981.9 Lorganisation de cration, modification,

    suppression dun nouveau profil . . . . . . . . . . . . . . . . . . . . . . . . 991.10 Lorganisation des volutions . . . . . . . . . . . . . . . . . . . . . . . . . 1011.11 Les principes de codification . . . . . . . . . . . . . . . . . . . . . . . . . . 1071.12 Les changements dorganisation . . . . . . . . . . . . . . . . . . . . . . . 110

    2. Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112.1 Dfinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112.2 Les scnarios dans la phase de Build . . . . . . . . . . . . . . . . . . . . 1112.3 Traitement des scnarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1132.4 Livrables raliser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142.5 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142.6 Les environnements du Systme dInformation . . . . . . . . . . 115

    3. Tests (recettage) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1163.1 Criticit des bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

    4. La reprise de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

    5. La formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205.1 Les supports de formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215.2 Passeport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

    6. Les livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.1 Les rgles de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.2 Les procdures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.3 Les manuels de formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266.4 Les dcisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276.5 La communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276.6 La stratgie de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

    7. Le Go/Nogo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

  • 5Table des matires

    Chapitre 5

    Le dmarrage du nouveau SI

    1. Le dmarrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1311.1 Les fentres de tir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1311.2 La prparation au dmarrage . . . . . . . . . . . . . . . . . . . . . . . . . . 1341.3 Gestion de crise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1351.4 Le "whiteboard". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1351.5 La "Go Back Procedure" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1371.6 Dconnexion des anciens systmes . . . . . . . . . . . . . . . . . . . . . 139

    2. Le post-dmarrage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1392.1 La productivit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1392.2 Limpact pour les partenaires. . . . . . . . . . . . . . . . . . . . . . . . . . 1402.3 Le support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

    3. La fin du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413.1 Les rles post Go Live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413.2 Le Kick Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423.3 Le REX chaud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1433.4 Le REX froid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

    4. Laprs-projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444.1 Pourquoi un aprs-projet ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444.2 La gestion des ressources humaines. . . . . . . . . . . . . . . . . . . . . 1444.3 La gestion des incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1454.4 Gestion des montes de version. . . . . . . . . . . . . . . . . . . . . . . . 1464.5 Gestion des croissances externes . . . . . . . . . . . . . . . . . . . . . . . 1474.6 La productivit froid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1484.7 Le tableau de bord de lERP . . . . . . . . . . . . . . . . . . . . . . . . . . . 1484.8 Organisation de la communication du SI . . . . . . . . . . . . . . . . 1494.9 BCMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

  • 6 Mettre en uvre un projet ERP

    Chapitre 6

    Les mthodes et outils essentiels

    1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

    2. Le fishbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

    3. WBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

    4. La matrice de dcision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

    5. Le suivi du planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

    6. Le suivi du budget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

    7. Le suivi des savings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

    8. Le support du comit de pilotage . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

    9. Les cartographies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659.1 La cartographie applicative . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659.2 La cartographie fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . 1669.3 La cartographie rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1679.4 La cartographie du hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 168

    10. La base de documents partags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

    Chapitre 7

    Le dessous des cartes

    1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

    2. La runion de lancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

    3. Le partage des cots (coups ?) - comit Europe . . . . . . . . . . . . . . . . 173

    4. Le suivi du planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

    5. Le choix dune option fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . 175

    6. La comptabilit par engagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

    7. Gestion par emplacement n1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

    8. Gestion par emplacement n2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

    9. La disquette. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

  • 7Table des matires

    10. Droits daccs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

    11. Dlai de paiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

    12. Les points de vue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

    12.1 Le DG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

    12.2 Le DG dune entit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

    12.3 Le directeur des achats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

    12.4 Le directeur financier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

    12.5 Le directeur commercial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

    12.6 Le directeur marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

    12.7 Le directeur qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

    12.8 Le directeur industriel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

    12.9 Les KU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

    12.10 Les utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

    12.11 Le DRH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

    12.12 Linformaticien du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

    12.13 Linformaticien dun pays . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

    12.14 Lintgrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

    12.15 Lditeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

    12.16 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

    Lexique anglais/franais

    1. Tableaux des anglicismes les plus courants dans la gestion dun projet ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

    Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

  • 73

    Chapitre 4

    La mise en place du projet

    La mise en place du projet

    1. La conception : le "design"

    1.1 BPR : Business Process Reengineering

    La mise en place dun ERP nest pas un projet informatique.

    Il nat de la volont dunifier, dharmoniser, doptimiser les fonctionnementsde lentreprise, quitte mme en changer compltement les process. Ceci atrs souvent comme consquence de crer une nouvelle organisation qui ex-cutera ces nouveaux process.

    Le BPR (Business Process Reengineering) est la rflexion qui consiste optimiserles process et les organisations dune entreprise.

    Comment dfinir ces nouveaux process ? En procdant de la sorte :

    Analyser les process actuels, parfois diffrents dune entit une autre, dunpays un autre.

    Les comparer avec les best practices du secteur ( laide dune expertiseexterne ncessaire).

    Les comparer galement avec ce que lERP peut modliser.

    lcroiseTampon

  • E

    dit

    ions

    EN

    I -

    All r

    ights

    rese

    rved

    74 Mettre en uvre un projet ERP

    Ensuite, et ceci afin de limiter la rsistance au changement, faites valuer lesdiffrentes possibilits par les acteurs du projet : Key Users, membre du comi-t projet

    Cette valuation doit se faire sur diffrents aspects :

    La dcision se prendra la suite de lanalyse des diffrentes options possibles,et en ayant pes les arguments sur toutes les dimensions nonces ci-dessus.Cette dcision sera prise au plus prs des oprationnels, dans le comit mtiersi elle ne concerne quun mtier, dans le comit projet intermtiers si elleconcerne plusieurs mtiers.

    En cas de non-consensus, la dcision suivra alors la procdure descalade (cf.chapitre Les acteurs du projet - Les instances de dcision).

    Arguments Option 1 Option 2 Option 3

    Fonctionnel +/- +/- +/-

    Cot +/- +/- +/-

    Savings +/- +/- +/-

    Efficience +/- +/- +/-

    Scurit +/- +/- +/-

    Simplicit +/- +/- +/-

    Prennit +/- +/- +/-

    Respect des obligations lgales +/- +/- +/-

    Autres +/- +/- +/-

  • 75La mise en place du projetChapitre 4

    1.2 Core Model

    Le Core Model est un ensemble de rgles de gestion, de process, dorgani-sations, de paramtres, de programmes, qui dfinit le fonctionnement duneentit de lentreprise.

    Autrement dit, il dfinit : Notre entreprise fonctionne comme cela, et elle estorganise comme ceci .

    quoi sert-il ?

    Il sert au dploiement de lERP sur une nouvelle entit de lentreprise, interneou externe. Il permet le dploiement rapide et vite de se reposer des questionsdont les rponses et dcisions ont dj t donnes lors du projet. Il vite lesdbats sur des objections du type chez nous ce nest pas pareil ou encore weare unique . Lors dune croissance externe, il permet, de plus, de gnrer lesmmes indicateurs pour toutes les entits, et donc facilite le pilotage de lanouvelle entit acquise, lment essentiel pour la direction gnrale.

    Ce Core Model peut tre vu comme strict et impos. Pour autant, il a t d-fini par tous, avec les arbitrages ncessaires et donc nest pas quelque chosedimpos par le haut , mais bien un modle bas sur les best practices tra-vailles par les oprationnels eux-mmes et les directions mtier.

    Ce Core Model, sil permet daller vite dans les dploiements car dj prdfi-ni, nest cependant ni fixe ni immuable. En effet, tout volue, et ce qui est leplus efficace aujourdhui ne le sera peut-tre plus demain. Ce Core Model doitdonc tre rgulirement remis en cause mais pas par nimporte qui et surtoutpas lors des dploiements sur des entits de mme nature.

    Le Core Model doit tre remis en cause par les Key Users et les directionsmtier suite aux vnements suivants :

    Mise en place dune nouvelle version (avec son lot de nouvelles fonctionna-lits).

    Demandes spcifiques de clients.

    Changement de lgislation.

    volution des best practices.

  • E

    dit

    ions

    EN

    I -

    All r

    ights

    rese

    rved

    76 Mettre en uvre un projet ERP

    1.3 Les scnarios de test

    Les scnarios de test sont des suites doprations qui vrifient que leSystme dInformation permet de drouler avec succs les nouveaux processavec la nouvelle organisation.

    Habituellement, ils se font la fin du projet pour vrifier que tout fonctionnecorrectement. Mais cest videmment une trs mauvaise habitude ! En effet,tester quelque chose qui existe dj, cest forcment tre influenc par ce quia t construit.

    Les scnarios de test font partie intgrante du design.

    La conception dcrit ce qui va tre construit, mais galement vrifie que ce quia t construit correspond bien lobjectif et rpond correctement auxbesoins. Bien entendu, il ne sagit pas de dcrire des crans remplir et desboutons sur lesquels il faut cliquer (puisque le systme nexiste pas encore),mais de formuler des scnarios de test mtier , sans rfrence aux outils, etdonc encore moins linformatique ou au SI.

    quoi servent les scnarios de test ?

    Ils permettent :

    De connatre le poucentage de ralisation du projet dans les phases deconception, de ralisation et de formation.

    Savoir si le scnario se droule correctement ou pas dans le nouveau systmedinformation.

    De raliser, par les quipes projet et les KU, des tests pertinents (contraire-ment aux tests improviss qui consistent cliquer nimporte o pour voirsil y a des bugs).

    De dcider au changement de systme (Go Live) si les scnarios sont testset suffisamment OK.

    De gnrer les documents de formation. En effet, quelle meilleure formationque de drouler le cas gnral et tous les cas particuliers ?

  • 77La mise en place du projetChapitre 4

    Quelques rgles pour rdiger des scnarios de test pertinents :

    Un scnario mtier dcrit des vnements et des actions.

    Les vnements sont soit une rfrence une date particulire (le 1er dechaque mois), soit une rfrence une interruption (je reois un appel demon client).

    Il ne doit pas faire rfrence au systme dinformation. Il doit pouvoir se drouler dans lancien comme dans le nouveau. Il doit pouvoir fonctionner sans systme dinformation.

    Cela permet de ne pas reproduire ncessairement les modes opratoiresactuels, les systmes ntant pas bass ncessairement sur les mmesconcepts.

    Il dcrit des situations trs concrtes.

    Il ny a pas de si dans un scnario : ce nest pas un logigramme. Sil y a un si cest en fait quil y a deux situations possibles, donc deux scnarios. Avec des noms de client, de produits, de fournisseur, de date, dheure, des

    quantits, des montants, etc. Il indique clairement qui (nommment) fait quoi et quel moment. Il indique, lorsque cest ncessaire, des lments de rapidit (pour cette

    action, il me faut 30 min).

    Commencer par le cas gnral, puis par les cas particuliers.

    Ne pas jargonner ni utiliser dabrviation sans dfinition.

    Faire rfrence la procdure qualit correspondante si elle existe, sinon in-former quelle nexiste pas.

    Le scnario doit tre conforme aux rgles de gestion de lentreprise. Dans lecas contraire, supprimer le scnario ou changer la rgle de gestion (arbitrageen Copil).

    Les donnes en entre dun scnario doivent tre gnres soit par un vne-ment extrieur soit par un autre scnario. Il est important de vrifier cetteconnexion entre les scnarios afin de vrifier quil nen manque pas ou quetoutes les donnes de sorties ont bien t identifies.

  • E

    dit

    ions

    EN

    I -

    All r

    ights

    rese

    rved

    78 Mettre en uvre un projet ERP

    Exemple 1 : ADV du devis la commande

    Aujourdhui, je reois une demande de devis de mon client Atlas pour50 exemplaires du produit X23 livrer dans son dpt dans 7 jours.

    Je demande au responsable de la production si cest possible.

    Il rpond quil a les produits en stock et quil pourra les livrer dans 7 jours sila commande est confirme au plus tard demain. Dans le stock, il bloque cesproduits jusqu demain.

    Je rdige le devis des 50 produits X23, avec pour prix unitaire 200 HT (prixque je trouve dans la grille tarifaire), soit 10 000 HT.

    Je lui applique 10 % de remise conformment au contrat que nous avonsavec Atlas, soit 1 000 HT.

    Le montant total est donc de 9 000 HT.

    La TVA sur ce produit est de 20 %, soit 1 800 .

    Le montant TTC du devis est donc de 10 800 .

    Jenvoie ce devis mon client Atlas en lui indiquant sa limite de validit.

    Dans lheure, il valide par crit mon devis.

    Je transforme ce devis en commande ferme.

    Je la communique au responsable de la production.

    Exemple 2 : ADV Facturation dune commande

    Aujourdhui, je reois linformation que la commande de mon client Atlas at expdie.

    Je vais rechercher son bon de livraison qui est conforme en quantit lacommande.

    Je le transforme en facture client avec les mmes quantits que lacommande ainsi que les mmes prix.

    La facture que je gnre est donc de 9 000 HT, 1 800 de TVA, soit10 800 TTC.

    Je vrifie que la date de rglement est conforme son contrat.

    Jenvoie mon client la facture.Performance : la gnration de facture ne doit pas prendre plus de 10 min.