Prerequisites In ERP Projects Paris Mines 2002
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Prerequisites In ERP Projects Paris Mines 2002

  • 1,982 views
Uploaded on

Conference held in Paris (Ecole des Mines) on organizational and legal prerequisites in ERP software projects

Conference held in Paris (Ecole des Mines) on organizational and legal prerequisites in ERP software projects

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,982
On Slideshare
1,980
From Embeds
2
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 2

http://www.linkedin.com 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Mise en place d ’un ERP : Pré requis techniques, humains, juridiques Philippe Roucou PHR Consultants et André Meillassoux ATM AVOCATS, Paris
  • 2. Sommaire :
    • Introduction
    • Pré requis techniques
    • Pré requis humains
    • Pré requis juridiques
  • 3. Introduction : syndrome du chef de projet. Les keys users ne sont pas disponibles… Il me faut du personnel… ou un spécifique… … Les temps de réponses sont mauvais… Avant le système faisait cela… La Direction n’a plus aucune visibilité… La recette est ajournée… Les retards s’accumulent Encore de nouveaux avenants au contrat d’origine … La conception générale est trop floue… Le contrat ne précise rien à ce sujet
  • 4. Introduction :Cycle de vie du Système d’Informations et risques de dérapages sur chacune des phases. BPR Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Post- implémentation Choix Mise en oeuvre S.I. Version 2 Ouverture/chgt SI Post- implémentation BPR Contrat Contrat
  • 5. Introduction : Conditions de succès : Pré requis techniques, humains et juridiques. Produit / Process Perfor- mances Processus/ Organisation (BPR) Réf. Système d’Information Pré requis juridiques Pré requis humains
  • 6. L’environnement du S.I. : les objectifs Produit / Process Perfor- mances Processus/ Organisation (BPR) Réf. Système d’Information
  • 7. Pré requis techniques : Fixer des objectifs opérationnels comme fil conducteur. Satisfaire les actionnaires Rentabilité des capitaux investis Bénéfices Trésorerie Prix Qualité Délai/flexibilté Satisfaire les clients Présentation de quelques cas concrets parmi une cinquantaine de projets réalisés Produit / Process Perfor- mances Processus/ Organisation (BPR) Système d’Information
  • 8. L’environnement du S.I. : le BPR Produit / Process Perfor- mances Processus/ Organisation (BPR) Réf. Système d’Information
  • 9. Pré requis techniques : Réussir le re-engineering des processus (BPR) pour atteindre les objectifs opérationnels visés. Workflows. (*)Document SAP © adapté. Avant-vente Commande client Appro stock Livraison Facturation Vente (ADV) PIC PDP MRP Ordre planifié OF Prod. D.A. Sélection fournisseur Commande fournisseur Entrée Marchandise Contrôle facture Achat Définition et mise en œuvre des processus cibles. Suivi de prod Paiement Fournisseur Règlement client Contrôle Logistique/Suivi financier Produit / Process Perfor- mances Processus/ Organisation (BPR) Système d’Information
  • 10. Pré requis techniques : Adopter le/les référentiel(s) métier(s) et les intégrer dans la démarche ERP. Calcul des besoins Calcul des charges Niveau 1 Niveau 2 Niveau 3 Niveau 4 Niveau 5 Gestion d’atelier PIC PDP MPS SOP Strategic Plan Plan stratégique Choix d’un référentiel : APICS, DGA/BNAE (SLI),… MRP SFC OPERATIONNEL DIRECTION Produit / Process Perfor- mances Processus/ Organisation (BPR) Système d’Information
  • 11. L’environnement du S.I. : Produits/process Produit / Process Perfor- mances Processus/ Organisation (BPR) Réf. Système d’Information
  • 12. Pré requis techniques : Fixer un choix d’organisation et analyser les produits/process dans leur évolution. Quelles spécificités pour l’ERP? Faire un benchmarking pour valider si nécessaire
    • Organisation :
      • Organisation commerciale, industrielle, financière, ressources humaines,
      • Organisation du reporting,
      • Gestion à l’affaire (couplage projet/MRP),…
    • Typologie produit/process :
      • Relation délai de livraison/délai de production,
      • Profil de famille de nomenclature : A, X, I, V.
      • Niveau de personnalisation des produits,
      • Niveau d’automatisation,
      • Méthodologie de conception des produits nouveaux,
      • Traçabilité,
      • Soutien logistique intégré (SLI), …
    Produit / Process Perfor- mances Processus/ Organisation (BPR) Système d’Information
  • 13. Déploiement du nouveau S.I Perfor- mances Produit / Process Processus/ Organisation (BPR) Système d’Information Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Post-Implémentation Choix Mise en oeuvre S.I. Version 2 Ouverture/chgt SI Contrat Contrat Post-Implémentation
  • 14. Première phase : le « choix de l’ERP ». BPR Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Post- implémentation Choix Mise en oeuvre S.I. Version 2 Ouverture/chgt SI Post- implémentation BPR Contrat Contrat
  • 15. Pré requis techniques : Réaliser un schéma directeur d’intégration pour définir la solution cible et la trajectoire. Analyse de l’existant Cartographie Initialisation Analyse des besoins Dossier d’expression des besoins Architecture globale Projet de schéma directeur Etude technique Etude économique Examen de la transition Evaluation globale Dossier des Solutions proposées Choix d’une solution Rédaction finale du schéma directeur Cartographie Progiciels Cible : 0 spécifique. Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 16. Pré requis techniques : Comment va s’intégrer l’ERP dans l’ensemble du S.I. cible ? Niveaux 3 et 4 SIT CFAO, prog Calcul, Prog API, CN ERP Gestion industrielle, finance Ressources humaines PDM Bureautique/messagerie/sécurisation Systèmes de supervision /gestion d’atelier (MES) et magasin (SCE) Machines , lignes de production, manutention et magasins manuelles/automatisées Niveau 2 Niveaux 0 et 1 EDI Internet Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 17. Pré requis techniques : Quelle architecture hard et soft. Ex : Plate-forme Université Paris 8. CFAO (Solidworks) Niveau 3 Niveau 2 SGDT ERP GMAO (PROMAINT) AMDEC (TOMI) MES Gestion d’atelier (HARMONY) Niveau 1 Rapprochement bancaire Rapprochement bancaire Atelier de fabrication de composants Superviseur magasin et poste Pal/Dépal 6 terminaux portables : Presse injection, Tour CN, Poste de contrôle (SPC), mode dégradé cellule. Superviseur Cellule flexible : CU 3 et 4 axes, Manut/chargt automatisés. Magasins matières premières, produits semis-finis et finis. Magasins Atelier de montage Postes de gravure, assemblage finition et emballage. Gestion KANBAN Bureaux Commercial, Finances, Personnel, Bureaux d’Etudes et des Méthodes , Logistique. Rapprochement bancaire Automates des CU 3 et 4 axes, du convoyeur et du chargt/déchargt automatisés. Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 18. Pré requis techniques : Choix de l’ERP.
    • S’appuyer sur une grille de choix pondérée multi-critères :
      • Intégration globale dans la solution cible du Schéma Directeur,
      • Adéquation technique de l’ERP,
      • Pérennité de la solution et des partenaires,
      • Expérience de l’intégrateur, de l’équipe,..
      • … .
    Constituer une équipe projet (Cf pré requis humains) Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 19. Deuxième phase : le « contrat». BPR Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Post- implémentation Choix Mise en oeuvre S.I. Version 2 Ouverture/chgt SI Post- implémentation BPR Contrat Contrat
  • 20. Pré requis techniques : Bien « border » techniquement le contrat avec l’ intégrateur.
    • Le contrat, établi à partir du cahier des charges de la maîtrise d’ouvrage, spécifie :
        • Au plan technique (en prenant en compte les résultats d’un benchmarking s’il a été effectué) :
          • Le périmètre du projet (modules concernés, spécification matériel et réseaux,..),
          • La réponse de l’intégrateur (standard paramétrage ou spécifique) pour chaque processus de cahier des charges, ou si le cahier des charges n’est pas assez précis une évaluation ligne par ligne des spécifiques prévus ,
          • Le volume item par item des interfaces et reprises ,..
        • Au plan méthodologique :
          • La méthode d’implémentation avec les grandes phases du projet, les livrables et les recettes associées.
    Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 21. Pré requis techniques : Choisir une méthodologie d’intégration dès la phase contractuelle. Construire le contrat autour (délai, délivrables,..) PHASE 1 : lancement du projet To : lancement Exemple : jalonnement sur la base d’un projet d’environ 1 an avant basculement. 1 mois 3 mois 3 mois 3 mois 3 mois 3 mois Tf : Recette finale PHASE 3 : maquettage (module par module) PHASE 4 : Prototypage (processus entier) PHASE 5 : préparation avant basculement PHASE 6 : Montée en charge PHASE 2 : Conception générale Benchmarking si nécessaire Basculement Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 22. Pré requis techniques : Bien « border » techniquement le contrat avec le Maître d’Œuvre (suite).
    • Le contrat avec la Maîtrise d’oeuvre spécifie (suite et fin) :
        • Au plan calendaire :
          • Les dates de réalisation de chacune des phases et les pénalités de retard associées,
        • Au plan « engagement de performances » du maître d’oeuvre :
          • Les résultats attendus : temps de réponse ,…
        • Au plan financier :
          • Le montant forfaitaire de l’intégration pour chacune des composantes : Paramétrage, spécifiques, interfaces , reprises, formation, matériel et réseaux,…
          • Nota : la forfaitisation des spécifiques, interfaces et reprises est un point de passage obligé difficile à obtenir des intégrateurs.
    Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 23. Pré requis techniques : Bien « border » techniquement le contrat avec le Maître d’Œuvre (suite).
    • Le contrat avec la Maîtrise d’oeuvre spécifie (suite et fin) :
        • En terme de garantie :
          • Prévoir une recette définitive trois mois après basculement (recette provosoire,..
          • … ..
    Au terme de cette première phase (« Choix ») Les orientations du Schéma Directeur sont confirmées Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 24. Troisième phase : la « mise en œuvre » de l’ERP BPR Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Post- implémentation Choix Mise en oeuvre S.I. Version 2 Ouverture/chgt SI Post- implémentation BPR Contrat Contrat
  • 25. Pré requis techniques : Déroulement de la méthodologie retenue au niveau contractuel. PHASE 1 : lancement du projet To : lancement Exemple : jalonnement sur la base d’un projet d’environ 1 an avant basculement. 1 mois 3 mois 3 mois 3 mois 3 mois 3 mois Tf : Recette finale PHASE 3 : maquettage (module par module) PHASE 4 : Prototypage (processus entier) PHASE 5 : préparation avant basculement PHASE 6 : Montée en charge PHASE 2 : Conception générale Benchmarking si nécessaire Basculement Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 26. Pré requis techniques : Phase 1 de l’intégration
    • Phase 1 : Lancement du projet :
      • Communication,
      • Organisation,
      • Planning,…
      • Livrables : planning, organigramme, plan de communication,…
    Rôle primordial du plan de communication, Renforcement de l’équipe projet. Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 27. Pré requis techniques : Phase 2 de l’intégration.
    • Phase 2 : Conception générale :
    (1) Y compris avec les jeux d’essais des Editeurs : IDES, VISION,… Processus actuels de l’entreprise Processus cibles de l’entreprise Processus standards de l’ERP Performances cibles de l’entreprise Alignement Benchmarking (1) Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 28. Pré requis techniques : Phases 3 et 4 de l’intégration.
    • Phases 3 et 4 : Maquettage et prototypage :
    Paramètrage de l’ERP + dossier Interfaces, reprises, spécifiques Confirmation configuration finale Etats, formulaires, droits d’accès Doc utilisateurs, manuel formation Spécifi- -cations générales Système « repré- -sentatif » du futur S.I. Recette Recette Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 29. Pré requis techniques : Phases 5 de l’intégration.
    • Phase 5 : Préparation avant basculement :
    Système « repré- -sentatif » du futur S.I. Recette Recette Formation Basculement Planif détaillée du passage en production Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 30. Troisième phase : « Post-implémentation » de l’ERP. BPR Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Post- implémentation Choix Mise en oeuvre S.I. Version 2 Ouverture/chgt SI Post- implémentation BPR Contrat Contrat
  • 31. Pré requis techniques : Post-implémentation du S.I Processus paramétrés dans l’ERP avec/sans spécifique(s) Evolution des paramètrages et des procédures Amélioration des performances de l’entreprise Procédures associées Choix Mise en oeuvre Ancien S.I. Nouveau S.I. Version 1 Contrat Post-implémentation
  • 32. Pré requis humains :
    • L’implication de la Direction Générale…
    • Le profil du Chef de Projet,
    • L’organisation du projet,
    • La mise en cohérence et la motivation des équipes : un point de passage obligé.
  • 33. Pré requis humains : L’implication de la Direction Générale…
    • L’implication de la Direction Générale devrait être permanente :
      • Lors du lancement du projet : note de lancement, photo avec l’équipe projet sur l’intranet,…
      • En cours de projet, dans les moments difficiles et dans les moments clés (Cf cohérence et motivation des équipes,…),
      • Lors des recettes, du basculement, pendant la montée en puissance,…
    • De façon générale, il est indispensable que l’équipe projet soit suffisamment solide pour traverser des périodes plus ou moins longues sans appui de la Direction…
    • Rechercher un/deux promoteur(s) du projet au sein de l’équipe de Direction,…
    L’implication de la DG : cela se gagne !!! (1) (1) En obtenant des résultats concrets dans l’avancement du projet
  • 34. Pré requis humains : Le profil du Chef de projet… Des compétences …..qui nécessitent de constituer au minimum un binôme (2 pers. en interne + AMOA ou 1 pers. Interne et AMOA – (1)) (1) Assistance à Maîtrise d’Ouvrage (AMOA)14
    • Profil de manager ,
    • Homme de terrain,
    • connaît bien les
    • processus opérationnels
    • Compétences informatiques
    • (hard et soft),
    • RH, juridiques,..
    • Forte expérience de
    • la mise en œuvre d’ERP
    • (plusieurs dizaines
    • de projets –AMOA-)
  • 35. Pré requis humains : L’organisation de projet… Des engagements…..vus sous les aspects techniques, humains et juridiques Quel schéma retenir ?? (Cf partie juridique) Contrat Contrat Comité de pilotage Equipe projet MOA Equipe projet MOE Sous-traitant 1 Sous-traitant 2 AMOA
  • 36. Pré requis humains : Mise en cohérence des équipes et motivation…
    • Constitution des équipes :
      • Utilisateurs clés,
      • Groupe de motivation,
      • Extension à l’ensemble des utilisateurs
    Comment constituer chaque groupe puis conduire le déploiement ???
  • 37. Pré requis humains : Mise ne cohérence des équipes et motivation… Choisir les bons acteurs… Cartographie RH 5 4 Une bonne capacité d’adaptation, de l’impulse… 3 6 2 6 1 8 3 5 6 4 2 9 8 7 Des leaders motivés… 10
  • 38. Pré requis humains : Mise ne cohérence des équipes et motivation… Choisir les bons acteurs… Cartographie RH Des managers,…..et des fonctionnels associés…
    • Les jeux,
    • Les messages cachés,…
    Une gestion des comportements…
  • 39. Pré requis humains : Mise en cohérence des équipes et motivation… Gérer la motivation…Quelques exemples
    • Mettre le tempo,
    • Communiquer en interne sur les événements,
    • Marquer les événements :
        • Primes, repas, séminaires,…
  • 40. Pré requis humains : Mise ne cohérence des équipes et motivation… … sans négliger la technique… … dans le cadre des pré requis juridiques… La mise en cohérence des équipes et la motivation sont les facteurs clés de la réussite….
  • 41. Plan de la seconde partie : juridique : 1.« pré requis juridique : le contrat »
    • 1. L’outil de gestion indispensable de votre projet : Un schéma contractuel clair
    • Nous examinerons les 3 schémas possibles
    • Et nous verrons lequel choisir : les avantages et les inconvénients
  • 42. Plan de la seconde partie : juridique 2. La gestion des dérapages
    • 2.1 Quelques constats et recommandations
    • 2.2 Que faire et comment faire en cas de dérapage « réel » de votre projet ERP ?
  • 43. RAPPEL DU PLAN : Seconde Partie : juridique
    • 1.   Le pré requis juridique : le contrat 
    • 2. Que faire en cas de dérapage de votre projet ERP ?
  • 44. Un outil essentiel à la réussite du projet : le contrat
    • Il faut mettre toutes les chances de son côté pour éviter les dérapages
    • Pour cela, il faut des instruments de gestion du projet
    • Au premier chef, un schéma contractuel clair pour les différents acteurs
    • Qui permettra de déterminer facilement les responsabilités
  • 45. 1. Identification du schéma contractuel de votre projet ERP (1) : pourquoi ?
    • Intérêt : le contrat est la clef de voûte du système :
    • Que ce soit pour :
      • La prévention des dérapages,
      • Le remède quand ils surviennent,
      • La réparation s’ils ont causé un retard ou un échec.
    • C’est évident : il faut s’être déterminé dès l’origine sur un schéma contractuel clair.
  • 46. 1. Identification du schéma contractuel (2) : un schéma clair, lequel ?
    • Avez- vous bien choisi les acteurs?
    • Qui sont-ils ? Sont-ils à la bonne place?
    • Éditeur, intégrateur, maître d’œuvre, fournisseurs divers. Où est la cohérence ?
    • Elle doit s’inscrire dans un schéma clair
  • 47. 1. Identification du schéma contractuel (3) : Quels contrats ?
    • un simple contrat de “licence”, avec l’éditeur de l’ERP ? :
    • Au centre du système : un contrat “d’intégration” de progiciel.
    • La question : qu’est-ce ?
    Non !
  • 48. 1. Identification du schéma contractuel (4) : lequel des 3 ?
    • Il faut se positionner au regard des trois schémas suivants :
    • Le contrat ERP : “ clé en main ”
    • Un schéma “sans intégrateur”
    • Un schéma avec un “intégrateur- maître d’œuvre ”
  • 49. 1. Identification du schéma contractuel (5) : Schéma A “ clé en main ” ?
    • Maître d’ouvrage
    • Entreprise générale
    • Sous traitants
    • Editeur
    • Hard-ware
    • Services
  • 50. 1. Schéma contractuel (6) : A - “ clé en main ” : Observations
    • C’est le schéma que très souvent vous recherchez : “une seule tête”
    • Un seul contrat uniquement avec l’entreprise générale
    • On se rassure avec le mot “clé en main”
    • Pourtant ce schéma ne convient pas
  • 51. 1. Schéma contractuel (7) : A - “ clé en main ” : non approprié
    • Car ce n’est pas l’esprit
    • Un projet informatique nécessite: votre implication totale , l ’expression de vos besoins
    • Or, un contrat « clé en mains » revient à confier toute la latitude à l’entreprise générale
    • Le projet perd en visibilité
  • 52. 1. Schéma contractuel (8) : A - “ clé en main ” : non approprié
    • De plus, dans la pratique, c’est le client qui, de fait :
    • Choisit l ’ERP (même si l’intégrateur préconise)
    • Souhaite ne pas payer un « mark-up » sur le prix de la licence
    • Conclut le contrat et gère, dans le temps, la relation : en direct avec l’éditeur
    • Conclusion : à rejeter
  • 53. 1. Schéma contractuel (9) Schéma B : Pas d’intégrateur : descriptif
    • Maître d’ouvrage
    • Editeur
    • Hard-ware
    • Services divers
  • 54. 1. Schéma contractuel (10) : Schéma B : Pas d’intégrateur : variante
    • Maître d’ouvrage
    • qualifié aussi de “maître d’œuvre”
    • L’Editeur
    • Les fournisseurs
    • La SSII
    • Par :
  • 55. 1. Schéma contractuel (12) : Schéma B : Pas d’intégrateur : ce qui manque
    • Il manque :
    • Un architecte ou « maître d’œuvre »
    • Qui ne soit : ni le client, ni les « artisans »
    • Qui conçoive et qui contrôle le projet
    • indépendamment des fournisseurs:
      • D ’ERP
      • De services
      • De hardware
  • 56. 1. Schéma contractuel (13) : Schéma B : Pas d’intégrateur : ce qui manque
    • C’est la situation où vous vous trouvez:
    • Quand vous ne contractez qu’avec l’éditeur de l’ERP et qu’il ne vous propose qu’un « contrat de licence »
    • Quand le prestataire de services ne prend pas un niveau d ’engagement suffisant .
  • 57. 1. Schéma contractuel (14) : Schéma C: avec un “intégrateur-maître d’œuvre”
    • Maître d’ouvrage
    • Intégrateur
    • ERP
    • Hardware
    • Le schéma qui convient :
    • Prestataires
  • 58. 1. Le schéma C qui convient : avec un “intégrateur-maître d’œuvre” : Pourquoi ?
    • Car il y a un “architecte”
    • Avec un fort niveau d’engagement : “maître d’œuvre”
    • Responsable de
      • La conception
      • La réalisation
      • La bonne fin du projet
    • Qui supervise, coordonne, voire gère la relation avec les contractants du maître de l’ouvrage
  • 59. RAPPEL DU PLAN de la partie juridique
    • 1.  Un outil : le contrat 
    • 2 . Que faire en cas de dérapage de votre projet ERP ?
    • 2.1 Quelques constats et recommandations
    • 2.2 Que faire et comment faire en cas de dérapage « réel » de votre projet ERP ?
  • 60. 2.1. « Dérapages » : Quelques constats
    • a) Un décalage entre l’attente initiale et le réel
    • L ’ERP vous est présenté comme étant théoriquement un schéma et une organisation idéaux
    • Constat : il y a un décalage permanent et inhérent entre l ’attente et le réel
  • 61. 2.1. « Dérapages » : Quelques Constats
    • b) Les traumatismes de l ’ERP
    • Un changement radical des « process » dans l ’entreprise
      • Plus rien n ’est pareil : les méthodes, les usages disparaissent ; même les tableaux de bord changent
    • L ’élimination programmée de ceux qui ne s ’adapteront pas
  • 62. 2.1 « Dérapages »,quelques constats
    • c) Des blocages psychologiques : craintes, suspicions, résistances
    • d) Une absence de visibilité : difficulté d ’appréhender l ’ampleur des changements et comment le projet sera vécu
  • 63. 2.1 « Dérapages »,quelques constats
    • e) L ’irruption des « développements spécifiques »
    • Certes il y a au départ l ’ERP « pur » : Le schéma standard : les fonctions préprogrammées de l ’ERP
    • Et pourtant :
      • le projet va nécessiter une série d ’adaptations non prévues au départ
      • pour garder certaines pratiques, faire certains compromis
  • 64. 2.1 « Dérapages »,quelques constats
    • ( suite ) L’irruption des « développements spécifiques » : conséquences
    • Une sortie de l ’épure du « tout spécifique »
    • Une complexification
    • Des coûts immédiats de production des développements
    • Des coûts parfois considérables pour les futures migrations de versions de l ’ERP
  • 65. 2.1 « Dérapages »,quelques constats a. Distinguer les dérapages
    • Les dérapages inhérents aux ERP qu ’il faut tolérer :
    • Ces retards, ces révisions, ces retours en arrière, ces arrêts pour une réflexion stratégique sont inhérents
    • De même : les résistances, les conflits, les mises en doute
  • 66. 2.1 « Dérapages » : Recommandations pratiques
    • Organiser l  ’accompagnement du changement
    • Veiller à une forte implication de la direction générale de l ’entreprise
    • Créer une réelle synergie entre la direction informatique et la direction générale
    • Mobiliser les équipes
    • Sinon, ce sont les causes premières d ’échec...
  • 67. 2.1 « Dérapages » : Recommandations pratiques
    • Mettre au jour les causes des résistances
    • Oser le parler-vrai sur les conséquences : changer les hommes
    • Ne pas laisser les informaticiens « en liberté » : garder le contrôle.
    • Il vaut mieux interrompre ou retarder un projet, quel que soit le coût, ou le préjudice d ’image, que de poursuivre sur de mauvaises bases, ou démarrer trop tôt
  • 68. RAPPEL DU PLAN :
    • 2.1 Quelques constats et recommandations
    • 2.2 Que faire et comment faire en cas de dérapage « réel » de votre projet ERP ?
  • 69. 2.2 La gestion des dérapages
    • a) Les actions préalables «en interne »
    • b) Le rôle des assurances
    • c) Les actions : La riposte graduée
      • amiables
      • contentieuses
  • 70. 2.2 La gestion des dérapages A) Les actions préalables en interne
    • Analyse : faire les constats objectifs nécessaires en temps utile
    • Utiliser la « grille » qu ’est le schéma contractuel pour imputer les responsabilités
    • Se faire assister par un expert-tiers pour avoir un avis extérieur
    • Reprendre la direction du projet
    • Obtenir un tableau clair des chefs de projet et de la D.S.I
  • 71. 2.2 La gestion des dérapages b. Le rôle des assurances
    • Solliciter la coopération de votre assurance
    • Les types d ’assurances susceptibles d ’intervenir pour un utilisateur :
    • Votre « assurance perte d ’exploitation »
    • Votre « assurance recours »
    • Votre éventuelle « multirisques informatiques »
    • Votre éventuelle « assurance garantie bonne fin de projet »
  • 72. 2.2 La gestion des dérapages b: Le rôle des assurances (suite)
    • L’assurance responsabilité civile professionnelle de votre prestataire est capitale !
    • Le réflexe: exiger du prestataire, dès la passation du contrat, sa police d’assurance
      • insérer une clause à cet égard dans vos contrats
      • s ’assurer que le plafond maximum de responsabilité est suffisant
  • 73. 2.2 La gestion des dérapages c : Les actions : la riposte graduée
    • 1) Il s ’agit de construire une stratégie avec le concours :
    • De votre expert-conseil extérieur, qu ’en général votre assurance vous délègue et rémunère
    • À l ’aide de votre schéma contractuel
    • Schéma revisité et validé par vos juristes (internes ou externes) : pour voir les forces et les faiblesses de votre situation
  • 74. 2.2 La gestion des dérapages c : Les actions : la riposte graduée
    • 2) Les actions amiables directes envers l ’intégrateur qui est au centre du système , surtout si le schéma contractuel est bon
      • Il a le rôle de maître d ’oeuvre
      • Le contrat l ’oblige à déterminer l ’origine du problème et à le résoudre
    • Attention! : Si vous tuez l ’intégrateur : vous mourez aussi...Il connaît bien votre entreprise : sans lui, tout risque d ’échouer complètement.
  • 75. 2.2 La gestion des dérapages c : Les actions : la riposte graduée
    • 3) Les solutions amiables avec l ’aide de tiers:
    • Expert-amiable conciliateur
    • Ou mieux : désignation d’un Expert judiciaire en référé
          • >on est encore dans un processus non contentieux
          • > mais qui peut devenir contraignant, si on le poursuit
  • 76. 2.2 La gestion des dérapages c : Les actions : la riposte graduée
    • 4) Quand tout a échoué : le stade ultime : la procédure judiciaire :
    • Action en responsabilité de l’intégrateur et/ou résolution du contrat (choix stratégique)
    • Demande de dommages et intérêts à titre de provision, devant le juge des référés
    • Recours aux clauses du contrat :
      • clauses de résiliation/résolution
      • pénalités/Obligation d’exécuter sous astreinte
      • substitution de prestataire
  • 77. A savoir : le régime de Responsabilité contractuelle de votre prestataire
    • Les différents régimes de responsabilité
    • responsabilité pour faute prouvée
        • l’obligation du prestataire est une obligation de moyen: la charge de la preuve repose sur le client
    • responsabilité sans faute
        • l ’obligation du prestataire est une obligation de résultat : la charge de la preuve repose sur le prestataire
  • 78. CONCLUSION des pré requis juridiques
    • Tout se joue en aval: une bonne négociation de votre contrat E.R.P.
    • En cas de dérapage :
    • Faire une analyse objec-
    • tive
    • Optez pour une gestion graduée des ripostes
    • Ne négligez pas les moyens amiables
  • 79. Pré requis techniques : Fixer un choix d’organisation et analyser les produits/process dans leur évolution.
    • Le contrat avec la Maîtrise d’oeuvre spécifie (suite et fin) :
        • Au plan calendaire :
          • Les dates de réalisation de chacune des phases et les pénalités de retard associées,
        • Au plan « engagement de performances » du maître d’oeuvre :
          • Les résultats attendus : temps de réponse,…
        • Au plan financier :
          • Le montant forfaitaire de l’intégration pour chacune des composantes : Paramétrage, spécifiques, interfaces , reprises, formation, matériel et réseaux,…
          • Nota : la forfaitisation des spécifiques, interfaces et reprises est un point de passage obligé difficile à obtenir des intégrateurs.
    Le budget initial (1) du projet est confirmé à l’issue de cette période avant passage à la période suivante (1) Budget initial parfois établi dans le cadre d’un Schéma Directeur d’Intégration