Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 1 livre papier acheté 
= la version en ligne automatiquement offerte. Cliquez ici

Les méthodes et outils essentiels

Introduction

La mise en place d’un ERP nécessite de maîtriser certaines méthodes et certains outils. Voici une liste de ceux qui me paraissent essentiels pour une bonne gestion d’un projet de ce type.

Le fishbone

Le fishbone, ou diagramme de FUGU ou encore PERT, est un outil très précieux. Simple, a priori, sa construction est la partie la plus réfléchie d’un projet.

De quoi s’agit-il ?

Comme nous l’avons dit, l’objectif d’un projet est un livrable, formalisé par une phrase à la voie passive, qui permet de mesurer si le livrable est terminé, si l’objectif est atteint. Le fishbone est l’éclatement de cet objectif en « sous-objectifs ». De la même façon, ces sous-objectifs doivent être du même type que l’objectif du projet, c’est-à-dire une phrase à la voie passive, mesurable. Cet objectif se décompose en sous-objectifs. Pour qu’un objectif soit atteint, il faut que tous ses sous-objectifs le soient.

Premier avertissement : le fishbone n’indique pas l’ordre dans lequel les actions vont être réalisées ! La relation entre deux livrables A et B signifie que la seconde ne peut pas se faire sans avoir réalisé la première.

images/DP05-01.png

Supposons que nous ayons à réaliser trois actions, A puis B, puis C.

images/DP05-02.png

Supposons que nous puissons faire ces actions indépendamment les unes des autres.

Dans ce cas, elles seront représentées comme des actions en parallèle dans le fishbone. En effet, avec trois ressources différentes...

WBS

Le WBS, ou « Work Breakdown Structure » se réalise après le fishbone. Il reprend tous les livrables du fishbone et en estime la charge.

Il est représenté par un tableau de la forme suivante :

Deliverable label

Estimating factor

factor

MDs/factor

MDs

1

Les supports de formation créés par les KUC en anglais

Nb de supports de formation

12

3

36

 

 

 

 

 

 

Il y a douze supports de formation à réaliser, chacun prenant 3 jours/homme (MD : mandays). Il faudra donc 36 jours homme pour réaliser ce livrable. C’est-à-dire, 36 jours (en délai) pour une personne, mais 18 jours pour deux personnes, etc. si ces livrables sont parallélisables.

Vous pouvez rajouter des précisions sur le type ou le coût des MDs (junior, senior…), ce qui permettra de transformer ces MDs en coût.

Il sert également à mesurer le coût :

Deliverable label

Estimating factor

factor

k€/factor

k€

100

Tous les serveurs sont achetés

Nb de serveurs

7

3

21

 

 

 

 

 

 

7 serveurs à 3 k€ le serveur, donnera un coût de 21 k€.

La matrice de décision

La matrice de décision est un outil également très puissant.

N’oublions pas que le plus grand risque d’échec pour un projet ERP réside dans la résistance au changement de certains acteurs.

« Décider, c’est dire oui, mais fatalement aussi, dire non ».

Prenons l’exemple de la construction d’un Core Model.

Chacun a ses pratiques, mais l’idée du projet est de converger vers une façon de faire, et quitte à en choisir une, la meilleure !

Comment décider de la pratique cible ?

Chacun aura tendance à dire que sa pratique est la meilleure, mettant en lumière les avantages, et en passant sous silence les inconvénients. Chacun aura aussi à cœur de pointer les inconvénients dans les pratiques des autres. Cela risque de générer des débats houleux, voire des conflits.

La meilleure façon de pacifier ces sujets c’est la matrice de décision.

De quoi s’agit-il ?

Prenons un cas simple : décider entre l’option A et l’option B.

Il s’agit de mettre ensemble les défenseurs de l’option A et les défenseurs de l’option B. L’objectif de cette réunion est de définir le plus objectivement les plus et les moins de chaque option, avec tous les points de vue : financier, fonctionnel...

Le suivi du planning

Une vision synthétique de l’état du projet peut être donnée par un jeu de couleur sur le fishbone. Ce fishbone coloré permet de communiquer simplement sur l’état d’avancement du projet. Ce n’est bien sûr pas un suivi fin du planning et ce n’est pas proactif. Pour le suivi fin du planning, il est conseillé d’utiliser des outils tels que MS Project.

Au-delà de l’outil, c’est une véritable mécanique qu’il faut mettre en place :

  • Chaque acteur du projet doit rentrer les temps qu’il a passés sur le projet et sur quels livrables. Il est préférable de parler en partition d’une journée plutôt qu’en heure : ¼ de journée sur ce livrable, ½ journée sur tel autre, etc. Le risque, en heures, est d’avoir des journées de 15 heures…

  • Chaque responsable de livrable doit indiquer le taux de réalisation : livrable réalisé à 50 %, 90 %… Mais attention à la mesure (cf. chapitre Le dessous des cartes - Le suivi du planning). Il doit ensuite estimer le reste à faire (Estimate to complete) en mandays. Exemple : un livrable a été estimé à 10MDs, il est réalisé à 50 % et a consommé 6MDs, le reste à faire, ETC...

Le suivi du budget

Il en va de même pour le suivi du budget :

  • Chaque responsable budgétaire réalise un reporting hebdomadaire des dépenses, analyse les écarts, ETC, et propose des corrections.

  • Les MDs externes déclarés dans le planning sont valorisés et font l’objet d’un suivi exactement identique aux autres dépenses.

La somme des dépenses prévues donne la vision budgétaire du projet.

Le suivi des savings

Le suivi des savings est le plus complexe. Il se fait généralement après le projet.

Pour cela, il faut comparer la situation actuelle avec la situation passée mais à périmètre constant (celui d’aujourd’hui), c’est-à-dire comparer la situation d’aujourd’hui avec le nouveau système avec la situation si le changement de système n’avait pas eu lieu.

Exemple : un groupe a trois entités dans trois pays différents avant le Go Live, et en a dix au moment de l’évaluation. Pour estimer les gains de la centralisation des équipes IT, il faut alors comparer les coûts de dix équipes locales IT, à une seule, plus importante, centrale.

Ces calculs sont approximatifs, car basés sur des moyennes, mais sont pour autant très crédibles.

Si les savings s’avèrent négatifs, c’est-à-dire un coût plus important après qu’avant, il est intéressant d’en comprendre la cause. La plupart des savings sont cumulatifs. De ce fait, ils augmentent d’année en année.

  • Changement de législation :

    Savings = (< nb de Systèmes d’Information à modifier s’il n’y avait pas eu de centralisation> x <coût moyen de développement + test + formation dans les anciens systèmes>)...

Le support du comité de pilotage

Le comité de pilotage se réunit à fréquence constante, le mieux étant chaque semaine. Sa fonction est de décider. Mais pour cela, il a besoin de certains éléments qui doivent être travaillés en amont par le comité projet.

Le comité de pilotage doit avoir une vue claire de la situation du projet.

Quels sont les problèmes principaux non résolus par les équipes projet ?

  • ressources non disponibles,

  • désaccord entre les membres de l’équipe projet,

  • et tout problème ne pouvant être résolu par les équipes projet.

Où en est-on ?

Suivi du planning

Sommes-nous en avance ou en retard ? Si nous sommes en retard, quelles en sont les causes ? Comment faire pour que cela ne se reproduise pas ? Les livrables en retard sont-ils sur le chemin critique ? En d’autres termes, y a-t-il une remise en cause de la date de démarrage ? Si c’est le cas, peut-on rattraper ce retard ? Ou peut-on réduire d’autres livrables pour garder la même date ?

Une vision panoramique des livrables réalisés/à faire peut se voir avec un fishbone coloré (vert = réalisé, jaune = en cours, blanc = à faire, rouge = non fait et devrait l’être à ce jour). Cela a l’avantage de voir l’état...

Les cartographies

1. La cartographie applicative

Elle décrit les applications du SI ainsi que leurs interfaces.

images/DP05-07.png

2. La cartographie fonctionnelle

Elle décrit quelle fonctionnalité est gérée par quelle application.

images/DP05-08.png

3. La cartographie réseau

Elle définit le schéma des sites et des réseaux (débits) qui les relient.

images/DP05-09.png

4. La cartographie du hardware

Elle décrit les salles machines mirrorées.

images/DP05-10.png

La base de documents partagés

Le projet va être l’opportunité pour formaliser, il va donc générer de nombreux documents. Certains vont être historiques (ce qui était avant le projet), ils seront donc peu consultés après le projet. Il est toutefois nécessaire de les garder car le passé éclaire toujours le présent. D’autres seront utiles uniquement pendant le projet : c’est la grande partie des documents générés. Ils doivent être accessibles aux équipes projet. D’autres encore vont être générés pendant le projet, mais vont avoir vocation à être utilisés pendant le projet, mais aussi après le projet, voire même ad vitam aeternam.

Quelques exemples :

  • Les règles de gestion vont découler des nouveaux process et organisation définis lors du projet. Pour autant, ces règles s’appliqueront bien après le projet. Et un nouvel entrant dans la société s’imprégnera plus rapidement du fonctionnement de l’entreprise s’il trouve un document décrivant les règles de gestion de son domaine. Ces documents sont certes générés par le projet, mais évoluent et s’adaptent après le projet : ce sont des documents vivants.

  • Il en est de même...