ERP « Enterprise Resource Planning » PGI : Progiciel de Gestion Intégré

2 DEFINITION Recours à un seul éditeur pour gérer les fonctions ou les processus d’une entreprise

3 DEFINITION moins absolue Recours à un seul éditeur pour gérer plusieurs fonctions ou plusieurs processus d’une entreprise Plusieurs ?

4 ERP I. Genèse II. Caractéristiques potentielles III. ERP & Flexibilité IV. Projets ERP V. Gouvernance des projets ERP

5 a) Origine : années 80 b) Croissance du marché c) Elargissement de l’offre 1.Genèse des ERP

6 a) Idéologie du BPR b) Viser un contrôle fort c) Standardiser les pratiques d) Affaiblir le pouvoir des DSI e) Réduire les coûts f) Mimétisme concurrentiel 2.Raisons d’adoption dans les GE

7 a) Structurer les systèmes de gestion b) Utiliser des compétences externes c) Accompagner la croissance d) Réduire les coûts e) Solution au problème « an 2000 » 2.Raisons d’adoption dans les PME

8 ERP I. Généalogie II. Caractéristiques potentielles III. ERP & Flexibilité IV. Projets ERP V. Gouvernance des projets ERP

9 1. Evolutivité 2. Portabilité 3. Intégration modulaire 4. Paramétrage 5. Référentiel unique ERP : caractéristiques potentielles

10 obtenue par : la portabilité la modularité le paramétrage Les actions d’évolution de l’éditeur Evolutivité : capacité d’évolution

11 1. Evolutivité 2. Portabilité 3. Intégration modulaire 4. Paramétrage 5. Référentiel unique ERP : caractéristiques potentielles

12 Capacité à fonctionner sur des configurations informatiques différentes Portabilité :

13 Facilite le changement d’environnement informatique Dépend de la gestion de configurations de l’éditeur Portabilité :

14 Les éditeurs n’adoptent pas toutes les configurations informatiques possibles mais seulement plusieurs systèmes parmi ceux devenus des standards de fait : Windows NT, architecture AS400, client serveur, SGBD standards… Relativisme de la portabilité :

15 1. Evolutivité 2. Portabilité 3. Intégration modulaire 4. Paramétrage 5. Référentiel unique ERP : caractéristiques potentielles

16 Du nombre de modules réalisés par l’éditeur De la qualité de l’architecture L’Intégration modulaire dépend

17 Plus le nombre de modules de l’éditeur est grand Plus l’entreprise dispose d’une gamme variée de fonctions et d’une possibilité d’élargissement Intégration : nombre de modules

18 Un système modulaire est composé de sous-systèmes (modules) relativement indépendants mais fonctionnant comme un tout intégré. Module : qualité de l’architecture

19 Nombre de modules adoptés par l’entreprise Couverture fonctionnelle

20  Une couverture fonctionnelle élevée améliore la transfonctionnalité, la circulation hiérarchique des flux et permet un fonctionnement efficient sans redondance et sans tampons Avantages de l’intégration modulaire

21  En cas de panne l’ensemble du SIC est bloqué Inconvénient de l’intégration modulaire

22 1. Evolutivité 2. Portabilité 3. Intégration modulaire 4. Paramétrage 5. Référentiel unique ERP : caractéristiques potentielles

23 Confère une généricité aux modules qui sont aptes ainsi à résoudre des problèmes plus larges (moins spécifiques) Paramétrage

24 Cette possibilité est obtenue par la gestion d’une base de règles L’activité de paramétrage consiste à sélectionner et activer, parmi l’ensemble des règles possibles, celles qui correspondent au contexte de l’entreprise Paramétrage

25 Plus le choix est large et plus le paramétrage est complexe Le re-paramétrage implique souvent un historique absent de données Les progiciels ne sont jamais omni- sectoriels mais plutôt plurisectoriels Paramétrage : la réalité

26 1. Evolutivité 2. Portabilité 3. Intégration modulaire 4. Paramétrage 5. Référentiel unique ERP : caractéristiques potentielles

27 Une base de données unique Uniformisation des interfaces homme-machine Référentiel unique

28 Homogénéisation inter fonctionnelle Cohérence interne du SIC Avantages du référentiel unique

29 N’est pas une caractéristique exclusive de l’ERP On peut y arriver avec un SGBD et sans ERP Mais le référentiel unique

30 ERP I. Genèse II. Caractéristiques III. ERP & Flexibilité IV. Projets ERP V. Gouvernance des projets ERP

31 Flexibilité : moyen d’atteindre la réactivité  Flexibilité opérationnelle  Flexibilité stratégique ERP : caractéristiques réelles

32 Flexibilité opérationnelle Flexibilité stratégique Evolutivité oui Portabilité oui Paramétrage oui? Modularité couverture fonctionnelle Oui mais… Référentiel oui

33 ERP I. Généalogie II. Caractéristiques III. ERP & Flexibilité IV. Projets ERP V. Gouvernance des projets ERP

34  Propriétés des systèmes faiblement couplés  Couplage faible et flexibilité stratégique ERP & le couplage de systèmes

35  Amortissent les fluctuations  Sous-assemblages autonomes  Moins coûteux à coordonner Propriétés des systèmes faiblement couplés

36 La couverture fonctionnelle Couplage et ERP

37 ERP I. Généalogie II. Caractéristiques III. ERP & Flexibilité IV. Projets ERP V. Gouvernance des projets ERP

38 Les phases 1. Avant projet 2. Projet 3. Mise en exploitation 4. Appropriation

39 Avant-projet : « ideas to dollars » Chartering  Activités types  Problèmes et erreurs communs  Métriques de la performance  Résultats possibles

40 Avant projet : Activités types  Faire émerger l’idée  Développer un scénario  Analyser l’existant  Définir des indicateurs de performance  Choisir une solution  Evaluer les changements nécessaires  Planifier de projet  Approuver le plan  Communiquer

41 Avant projet : problèmes et erreurs courants  Pression des offreurs  Scénario irréaliste  Mauvaise compréhension des besoins  Pas d’ indicateurs de performance  Solution retenue inadéquate  Changements nécessaires sous-évalués  Choix inapproprié des partenaires  Stratégie de migration et de projet inexistante

42 Avant projet : performance attendue  Mesure souvent non formalisée Qualité du scénario  Alignement avec la stratégie  Pertinence des indicateurs clés  Adéquation du budget et du plan  Intelligibilité des contraintes et des paramètres du projet

43 Avant projet : Résultats possibles  Abandon de l’idée  Décision de lancer le projet  Qualité des paramètres du projet  Qualité du scénario

44 Les phases 1. Avant projet 2. Projet : Rollout 3. Mise en exploitation 4. Appropriation

45 Projet : « dollars to assets »  Organiser l’équipe  Réaliser le BPR  Gérer le changement  Paramétrer  Convertir  Tester  Intégrer  Former  Documenter

46 Projet : problèmes et erreurs courants  Equipe insuffisamment transverse  Incompétence des prestataires  Paramétrage inadéquat  Conversion et intégration déficientes  Budget formation sous-estimé  Documentation du projet insuffisante  Dépassement budgets, délai

47 Projet : performance attendue  Budget  Délai  Périmètre (envergure)

48 Projet : Résultats possibles  Atteinte des objectifs projet  Budget  Délai  Périmètre  Techniques  Atteinte des besoins métiers  Fonctionnalités  Performance organisationnelle  Performance opérationnelle

49 Les phases 1. Avant projet 2. Projet 3. Mise en exploitation : shakedown 4. Appropriation

50 Mise en exploitation : « assets to impacts » Activités types  Corriger les bogues  Ajuster les performances

51 Mise en exploitation : problèmes et erreurs courants  Diagnostics difficiles  Résolution des problèmes de performance difficile  Retour aux anciennes pratiques  Dysfonctionnement des opérations  Dépendance forte des opérations par rapport aux utilisateurs clés ou aux informaticiens  Apprentissage collectif insuffisant

52 Mise en exploitation : performance attendue  Temps de réponse  Taux d’indisponibilité  Impacts momentanés sur la qualité du travail  Impacts momentanés sur le stress des employés  Impacts momentanés sur les clients et les fournisseurs

53 Mise en exploitation : Résultats possibles  Terminaison du projet  Niveau et qualité des objectifs atteints  Impacts sur les affaires et les opérations  Réponse aux besoins satisfaisante ou au contraire insatisfaisante  Utilisation normale de l’outil

54 Les phases 1. Avant projet 2. Projet 3. Mise en exploitation 4. Appropriation : ownard & upward

55 Appropriation : « impacts to outcomes » Activités types  Audit de projet  Amélioration continue des opérations, de l’apprentissage  Migration vers de nouvelles versions

56 Appropriation : problèmes et erreurs courants  Pas d’évaluation des résultats  Pas de montée de versions  Turn over des compétences  Apprentissage collectif faible

57 Appropriation : performance attendue  Rarement mesurée  Indicateurs :  Amélioration de la performance des opérations  Croissance de l’apprentissage et des compétences  Facilité de la migration et des montées de versions

58 Appropriation : Résultats possibles  Terminaison du projet  Niveau et qualité des objectifs atteints  Impacts sur les affaires et les opérations  Réponse aux besoins satisfaisante ou au contraire insatisfaisante  Utilisation normale de l’outil

59 ERP I. Généalogie II. Caractéristiques III. ERP & Flexibilité IV. Projets ERP V. Gouvernance des projets ERP

60 Stratégie managériale des dirigeants 1. Choix et sélection d’une solution ERP 2. Cible de la couverture fonctionnelle 3. L’arme stratégique de rupture : le BPR