Les méthodes et outils essentiels

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.

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

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...

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 :

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.

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 ?

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...

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 :